Service
The workbook the team actually runs on
Somewhere in most firms there is a workbook that is really the operating system: fifteen years of rules in formulas, written by somebody who has retired, that nobody will replace because nobody knows what it does. That is not a spreadsheet problem. It is undocumented software, and reading undocumented software written by somebody else is the work this practice already does on station backups, point lists and register maps.
- Workbook audit
- Rules written down
- Contradictions found
- One bounded slice
- Export back out
First the audit, and it is a deliverable on its own
One to two days, fixed price, and what arrives is a written report rather than a proposal. It can be the whole engagement: plenty of firms read it, fix two things themselves, and keep the sheet for another five years. That is a good outcome and it is not a failure of the sale.
| What the report contains | Why it is the part worth buying |
|---|---|
| Every rule the workbook encodes | Written as sentences, not as cell references. This is the document that was never written, and it is the thing of value even if no software is ever built: it is what lets anybody other than the author change the sheet safely. |
| The rules that contradict each other | A sheet that has been edited for a decade usually has two places that disagree about the same thing, and the one that wins depends on which tab you are reading. Naming those pairs is the finding that changes a decision most often. |
| Which cells are inputs, and which are dead | Columns nobody fills in, tabs nothing reads, and the handful of cells that actually drive the result. A sheet with forty columns usually has six that matter. |
| What is hard-coded and should not be | Rates, factors, thresholds and dates typed into formulas rather than held in one place, so changing one of them means finding all of them. These are also where a silently wrong answer comes from after somebody updates one copy. |
| What breaks if protection is dropped | Which formulas a user can overwrite by accident, where a paste destroys a rule rather than a value, and what has no way of telling you it has happened. |
| The honest verdict on replacing it | Including, often, that it should not be replaced. A workbook that one person uses twice a month is not a web app waiting to happen, and saying so is the difference between an audit and a sales call. |
Why this is the same work as the rest of this site
Reading a file somebody else wrote and reporting what is wrong with it is the whole of the free tools on this site: each one takes an artefact produced by another system — an EDE export, a point list, a set of jars, a station backup — and reports the defects in it. ede-check is the closest analogue to a workbook: it parses a CSV-shaped file written by somebody else and reports what is wrong with it, and its own repository ships a deliberately broken sample so the output can be seen before anybody sends anything real.
For a workbook there is now a program as well as an audit:
workbook-scan opens an .xlsx as the zip
of XML it is and reports what is in the bytes — formulas saved holding an error,
links into files that may be gone, approximate VLOOKUPs. It is free, it
runs on the machine the sheet is already on, and it is the file-format half of the first
table above. The rest of that table is a person reading formulas, which is why the audit
exists and the program is not it.
The Niagara half of this practice is the same job at a larger size: a migration where the documentation and the code disagree, and the code is the only thing that is true. The integration audit is that work on an estate rather than on a sheet. A spreadsheet is a smaller, more private version of exactly that problem.
Then one slice, if the audit says so
A bounded slice becomes a web app
Not the whole workbook. The one part that hurts most — usually the step several people need at once, or the one where a paste can destroy a rule. The rules the audit wrote down are preserved and named, several people can use it at the same time, every change has a history, and the data exports back out in a format a spreadsheet can read.
Quoted after the audit, never before
A quote for “replace our tracker” written before anybody has read the tracker is a guess dressed as a price. The audit is what makes the number honest, and it also makes us the only bidder who has read the thing. If the audit says the slice is not worth building, that is in the report.
Export back out, on purpose
Whatever gets built exports to the format the sheet already uses, so the team is never locked in by the thing that was supposed to help them. This is the same ownership position as the rest of the practice — see what a handover contains.
What is explicitly out of scope
Not a rewrite of every tab. Not a mobile app. Not data entry or data cleaning by volume. Not hosting on infrastructure we do not control. Each of those is named in the written scope before anything starts, because the exclusions are what stop a fixed price becoming an argument.
Search demand for this was measured, and it is zero. Nobody types “convert excel spreadsheet to web app” or “spreadsheet automation services” into a search engine in any volume we can detect. This page exists so that a conversation already in progress has somewhere to send a click, not because anybody expects to be found by it — and saying so here is more useful to you than a page pretending to be the market leader in a market with no searches in it.
The plumbing version, which is smaller
Sometimes the answer is not an application at all: a scheduled export, a normalisation between two systems that disagree about a format, a report that builds itself, an alert that fires on a result rather than on an exit status. That last one is a real and common defect — a job that checks whether it ran rather than whether it did the thing it ran for. Web and app builds, and the pipeline that keeps them up covers that half, and it is often a day rather than a project.
Deliverables
What you actually receive
Fixed price per deliverable, quoted against a written specification. No hourly billing, and no price before the scope is in writing.
| Deliverable | Detail |
|---|---|
| The audit report | What the workbook encodes, rule by rule, in sentences: the contradictions, the dead cells, the hard-coded values, what breaks if protection is dropped, and an honest verdict on replacing it. |
| A written scope for the slice | Only if the audit says one is worth building. What it does, what it explicitly does not do, and the fixed price against it. You keep it whether or not you proceed. |
| The slice itself | In a repository you own, with the rules from the audit named in the code rather than reimplemented from memory, and a schema that still makes sense after the second change. |
| Export back to a spreadsheet | The data out in the format the team already uses, so nothing about this engagement makes it harder to leave than it was to start. |
| A short operating note | One page: how to run it, what it refuses and why, and what to do on the morning something fails. |
Also
Other services
Niagara 5 migration
Niagara 5 readiness audits and migration, including JACE 8000 to JACE 9000: which third-party modules survive the new runtime and mandatory signing.
Custom modules & drivers
Bespoke Niagara rt, wb and ux modules and drivers written against the Baja API: pure Java, signed, and stamped to install across a mixed estate.
Operator graphics
Niagara operator screens built once and reused: standard PX plant sheets bound by relative ORD, bajaux web widgets and dashboards, and a written standard.
Station engineering
JACE controller and Niagara station setup end to end: platform commissioning, TLS, users, roles, BACnet and Modbus, tagging, histories, alarms, backups.
Workbench tooling
Custom Workbench views and tools for repetitive Niagara work: bulk renaming and retagging, station audits, provisioning helpers and module inventories.
IoT & LoRaWAN
Custom IoT and LoRaWAN builds: decoders that survive a station, a self-hosted ChirpStack server, MQTT, and the points or dashboards the readings become.
Integration audit
A fixed-scope paid audit of an existing Niagara integration: what talks to what, where it breaks, and what fixing it would take.
Protocols & data
Field protocol integration and the data behind it: BACnet, Modbus, M-Bus and MQTT, into a building system, a database or a dashboard.
Web, apps & DevOps
Web and app builds with the DevOps around them: front end, backend, the database under it, and the build, deploy and monitoring work that keeps it up.
Website design
Remote website design services for small firms: a few real pages, fixed price, and a measured handover — HTTPS, broken links, Lighthouse, page weight.
Next step
Send the sheet, or the sheet with the numbers blanked.
A description of a spreadsheet is worth nothing to either of us — the rules are in the formulas, and the contradictions between them are the finding. If the numbers are commercial, blank them and leave the formulas; the audit reads the logic, not the values. What comes back is what it encodes, in writing.