What you own when the job ends

Who owns the programming and the point database

You do. The station, its point tree, the histories, the schedules and the graphics are yours and always were; nothing we do makes a copy of them that lives with us. For bespoke code the source is in the scope, named in the quote before anything is built, and it is handed over with the build instructions that turn it back into the jar you are running. That is self-interested as much as generous: the most expensive problem in this market is a module whose author has gone and whose source nobody holds, and the work we are hired for is usually exactly that problem. There is no version of this practice that adds to the pile.

The one thing we keep is the right to reuse general technique - how a driver polls, how a widget is structured - in later work for other people. Your points, your plant, your names and anything specific to your site are not that.

What happens to credentials and remote access if you replace us

Every job ends with a credential inventory: a list of what exists, who holds it, and what it is bound to, with no secret values written in it. The list is shaped like this.

What a portable export contains

A handover is only portable if a developer who has never met us can rebuild it. So the export is the inputs, not just the outputs:

• The module jar and its source, with the build instructions and the Niagara version it is stamped for.
• A station backup taken at handover, so the configuration that was working is a file rather than a memory.
• The scripts - whatever was used to import, convert, generate or check, including the throwaway ones, because they are the record of how the points got their names.
• The mapping sheet: which field address became which point, in a form a spreadsheet opens.
• A runbook of one or two pages, described below.

We charge for the work, not for being the only one who can touch it.

The runbook

One or two pages, written for whoever is on site at the time rather than for us. What the thing does, in a sentence you would use yourself. Where it runs - which station, which host, which service. How to restart it. What breaks first and what that looks like on a screen. Who to call, and what is and is not covered. It is about an hour's work per job and it is the difference between a system that is quietly abandoned and one that gets fixed.

Two tests most handovers skip

Replay. For every step that moves data, the handover says how it recognises work it has already done - and then it gets killed halfway and re-run, in front of you if you want. In this trade the cases that bite are a point re-import creating a second set of proxy points, a history import writing the same records twice, a schedule sync re-applying an override somebody removed on purpose, and an alarm route firing again on a station restored from backup.

An outcome check rather than a run check. A monitor that asks whether a job exited cleanly will report green on a job that wrote nothing. The assertion has to be about the result: this many history records landed, this point reads a plausible value, this file has more than zero rows. “It ran green” is the bug, and it is as easy for us to write as for anyone.

Response time, plainly

One business day to a reply, and that is the commitment rather than a target. The working day here is UTC+5: a message sent on a North American afternoon is answered the following morning our time, and a European afternoon is usually the same evening. Nothing on this site promises an hour, or around the clock, or a duty rota, because none of those would be true.

If a piece of work genuinely needs a faster written response than that - a station carrying something that cannot wait a day - say so while it is being quoted. The answer may be that we are the wrong people for that part, which is a better outcome for both of us than a number in a contract that nobody can keep.

How the risk sits

This is the question that decides a subcontract, and it gets asked before the money one: if we write something and it goes wrong, whose problem is it. Three answers, all of them already how we work rather than terms invented for a page.

The customer stays yours. We work behind you. We do not contact your client, we do not appear in front of them, and nothing we write carries our name into a screen they look at unless you ask for it. The relationship you spent years building is not a thing we are quietly competing for.

Scope is fixed and agreed in writing before anything starts. What is being built, what finished means for it, and what it costs - settled first, so there is no open meter and no conversation later about whether something was included. If the work turns out to need something outside that, you hear it as a separate question rather than as an invoice.

A defect inside thirty days of handover is ours. If what we wrote does not do what the scope said it does, we redo or fix it at no charge, and that is standard rather than something to negotiate for. It is a window on our own work, which is the honest shape of it: it does not cover a device that fails, a change somebody else makes to the station afterwards, or a requirement that turns out to have been different from the one in writing.

What is deliberately not here: a position on insurance cover. A warranty on our own work and an insurance policy are different answers to the same question, and putting the second on a website because it sounds reassuring is how a sentence ends up costing somebody real money. If cover needs stating for your procurement, ask - you will get a direct answer from the person who would be signing it.

Why this is written down at all

What kills these engagements is rarely the technology. It is that three months later the thing quietly stops working, nobody on your side can fix it, and the work gets routed around by hand instead - which nobody reports, because an automation that broke is embarrassing for everyone. Every item above exists to make that failure recoverable by somebody who is not us.

The same package is a line in the quote rather than a paragraph in a pitch: fixed price includes the runbook, the credential inventory, the replay test and a portable export. If you are comparing us with somebody else, ask them these three questions and compare the answers rather than the adjectives.