Software Pile serves systems integrators, OEMs, and facility teams across the United States, Canada, and international markets. Niagara module and driver development is naturally remote-friendly: we develop and test against your station exports and target hardware profiles, then support commissioning where the buildings are.
How Remote Delivery Works
Projects run on a clear cadence: a shared plan, milestone demos, and written status you can forward to anyone. All work lives in source control with documented setup, so you own the code and the knowledge – not just the deliverable. We test modules against your Niagara version and host IDs before anything ships, so remote delivery does not mean surprises at the site.
Secure Collaboration
Access is scoped per project: least-privilege credentials, agreed data-handling rules, and communication over the channels your organization approves. We work in your systems where policy requires it.
Time Zones and Communication
We overlap working hours with your team for standups and reviews, and keep decisions in writing so progress never blocks on a meeting. Communication cadence – daily, twice-weekly, or milestone-based – is agreed at kickoff and kept.
Onsite Options
Onsite commissioning, site surveys, and hands-on Workbench sessions are arranged as projects require – commissioning support is the most common onsite need in Niagara work.
International Engagements
International clients are onboarded with clear contracting: jurisdiction, invoicing currency, IP assignment, and data-protection terms agreed up front. Support-hour arrangements are set to your business day.
Tell us where your team works and what the project needs – we will propose a delivery model that fits.
How This Work Is Delivered, and Where
Software Pile delivers Niagara engineering remotely by default, and as a hybrid engagement when a project needs somebody on site. Clients are in the United States and internationally.
Onsite attendance is not a standing service with a fixed travel radius behind it. It is arranged per project, agreed during scoping, and priced with the rest of the work. Cross-border engagements bring contracting questions with them, including jurisdiction, invoicing currency, intellectual property terms and data-protection obligations, and those are settled in the contract rather than assumed from a web page. Raise them early.
What Remote Delivery Handles Well
Module and driver development, Workbench tooling, UX modules, BQL reporting and station model review are all delivered this way. The work happens against a station export and a test target running your Niagara version, and it is reviewed with you before it is scheduled onto a live site.
UX work carries one caveat that has to be planned for. A live view or a WebSocket that behaves on an engineering laptop can fail on the operator workstation because of a proxy, a firewall or an idle timeout in between, so the real network path has to be exercised on site or through a representative connection before handover. Migration assessment carries no such caveat: inventorying an AX station, identifying unsupported components and planning conversion is largely a desk exercise performed on an export, so migration scoping can be done without a site visit.
What Still Needs Somebody Standing There
The physical layer does not yield to remote access. RS-485 termination and biasing, an MS/TP trunk with a wiring fault, a device with no power, a controller that needs replacing, and any situation where nothing is reachable because the network path itself is the problem all require presence.
Commissioning is the other one. Verifying that a write actually moves a damper means somebody watching the damper. We say during scoping which tasks fall into this category, because a plan that assumes remote commissioning tends to unravel on site. Those visits are arranged for the project.
What Makes a Remote Engagement Work
Access and information gathered at the start remove the friction that otherwise appears halfway through.
- A station backup or export, and the Niagara version and host details for every target
- A non-production station or spare controller to test against where one can be made available
- The access method and its real constraints, including whether sessions need supervision or a change window
- A named technical contact who can answer questions about site history without a formal request
- Any existing naming or tagging standard, even an informal one, so new work matches what exists
Working Alongside Your Own Field Team
Some integrators want their own technicians keeping the site relationship, and that arrangement works. One split that works cleanly is development and testing handled by Software Pile, site execution handled by your team, with written commissioning steps specific enough to follow without a call.
When results come back, we review them against what the tests expected. That keeps your technicians in front of the client while the specialist work happens elsewhere.
Handover You Can Actually Use
The goal of a completed engagement is that another engineer can rebuild the module from the repository without calling us. That means source control, documented build steps pinned to a Niagara version, dependencies recorded, and notes explaining why non-obvious decisions were made.
Working code with no build instructions becomes unmaintainable at the next Niagara upgrade, which is a slow problem that surfaces long after everyone has signed off. Reproducibility prevents it, and it belongs in the scope from the first day of the project.