Questions we get asked before a first project

Both. Most production work is on Niagara 4, because that is what is installed. New code is written so the same source also builds for Niagara 5 when you need it. Modules are stamped to the oldest Niagara version you have to support, not to the newest one available, so one build covers a mixed estate.

Yes. Everything is pure Java plus JavaScript and CSS resources, with no native code, so one build runs on an ARM JACE and on an x86 Supervisor without a separate compile. Modules are kept small deliberately, because a JACE has a fraction of a laptop's processor and memory.

Yes. Niagara 4 ships with niagara.moduleVerificationMode=medium, which requires a certificate the host trusts, and hardened sites run high, which requires a CA-issued one. Niagara 5 makes a valid signature mandatory with no grace period. Tell us which mode your hosts run and the signing arrangement is matched to it before delivery, not after.

For bespoke work, yes, on request and in scope. The reason is self-interested as much as generous: the single most expensive problem in this market is a module whose author has disappeared and whose source nobody holds, and we would rather not add to the pile.

Fixed price per deliverable, quoted against a written specification. No hourly billing. The specification comes first and is yours whether or not you proceed; if scope changes, the specification changes first and the price follows it.

A PX sheet is a graphic your own engineers can open and edit in Workbench. A bajaux widget is HTML, CSS and JavaScript wrapped as a Niagara component, which drops into a PX sheet like any other widget. Use PX where engineers must be able to edit without a developer; use bajaux where a view has to be responsive, carry a brand, or do something no stock widget does. Most sites want both.

If the source exists, yes — porting, re-signing and a regression pass are routine. If the source is gone and the vendor is not coming back, the honest answer is usually to rebuild the function rather than reverse-engineer a jar, and that gets said plainly at quoting time rather than discovered halfway through.

A machine-generated inventory of every third-party module across the estate — vendor, version, signature state and stamped Niagara version — with a verdict per module of rebuild, port, replace or at-risk, the reasoning behind each verdict, and a sequencing plan covering what must happen before any controller is swapped.

No. Niagara 4 is supported to 2028. Niagara 5 is expected to reach general availability around the end of 2026. Dates published around licence transfer are commercial deadlines for a discount rather than a point at which anything stops running. Plan for the migration; do not let anyone panic you into it. Confirm current dates with your distributor.

No, and deliberately so. The widget code, the config files and the ORD strings are exactly what a station would run, but the station behind them is a simulator running in your browser. Publishing a live connection into somebody's building would be a poor idea.

Systems integrators and controls contractors who need a module or a widget set they do not have time to write, distributors whose customers are asking for something outside the stock catalogue, and building owners with an estate and a migration to scope. Work is remote.

No. This is an independent development practice. Niagara, Niagara Framework, JACE, Workbench and Tridium are trademarks of Tridium, Inc., used here only to describe what the work is compatible with.