An engineering studio built around one core, with a team per project

Why this exists

The Niagara ecosystem has a strange shape. It is the building management system in a very large number of buildings, it has a capable and open module architecture, and yet the market for third-party modules is served by a handful of vendors. Most BMS integrators who need something outside the stock catalogue either do without, or pay for a bespoke build from whoever is nearest, and then discover three years later that nobody holds the source.

This practice exists in that gap: build the thing properly, sign it, stamp it so it installs across a mixed estate, document it for the engineer who has to commission it, and hand over the source so the module outlives the supplier.

How the work is approached

Each constraint below exists because ignoring it is how Niagara work fails. No native code, because a native library will not load on an ARM controller. Stamped to the floor version, because a module stamped too high is refused outright. Signed, because verification modes tighten in every release and become absolute in Niagara 5. Small, because a JACE has far less headroom than the laptop it was developed on.

The same discipline applies to the front end. The widgets shown in the demos are built on a documented token layer — the same one this website is built on — so a client theme is a re-point rather than a rewrite, and a view that must also render inside Workbench is written to the browser engine Workbench actually embeds rather than to whatever shipped in Chrome last month.

Working together

Engagements are remote and quoted as a fixed price per deliverable against a written specification. The first conversation is half an hour and is free, and it is allowed to end with a recommendation that costs nothing — a stock feature you had not found, or a configuration change that removes the need for a module at all.

Estates are rarely uniform. A single client often has stations on Niagara AX, on several Niagara 4 point releases and on nothing at all yet, with HVAC plant from four vendors underneath. Work is scoped against the version floor that estate actually has, not against the newest one in it.

Working behind somebody else's name

A large share of this work arrives through somebody who is not the building owner: a consultant, a main contractor, a vendor's own engineer, another integrator carrying a job that has one piece in it they do not want to build. In front of their client, the work is theirs. Three things hold on every job of that kind, and they are worth stating rather than leaving to be asked about.

The name on it is yours. A module's vendor string, the cover of a specification, the header of a handover note — all of it is set to whoever the client is buying from. A module can be handed over for you to sign with your own code-signing certificate, so the signature does not introduce a name either. There is no watermark, no about box and no link home hiding in a graphic.

Your client stays your client. There is no contact with them except through you, during the job or after it, and no later approach — not a follow-up, not a newsletter, not a "we worked on your site" mail two years on. No client, employer or partner is named anywhere on this site; the case studies here are anonymous and stay that way, which is the same promise seen from the other side.

The specification is yours. Whoever commissions written work owns it — the specification, the audit report, the source and the right to hand the whole lot to a different engineer next time without asking. Nothing is held back to make the next job compulsory. The point of documenting a module properly is that somebody else can pick it up, and that is as true when the somebody else is a competitor.