Service
Web and app builds, and the pipeline that keeps them up
A site or an app is two jobs, and the second one is where it fails in public: the thing itself, and the pipeline that builds, ships, renews and watches it. A redirect nobody added, a certificate nobody was watching, an asset still requested over http, a link that has answered 404 since the last rename — none of those are design problems, and all of them are visible from outside.
- Front end
- Backend and APIs
- Databases
- CI and deploys
- TLS and monitoring
- n8n and webhooks
Two halves, and the second one is where it fails
Everybody scopes the build: the pages, the screens, the API, the schema, the background work behind it. What decides whether the thing is still serving in six months is the other half — the deploy, the certificate, the redirect, the monitoring, the check that fails before a visitor finds the defect. That half is also the half a stranger can measure from outside without an account and without anybody's permission, which is why the notes under this page are written as measurements rather than as advice.
What this covers
The build itself
Front end, the backend behind it, and the database under that: screens people use, an API other systems depend on, a schema that still makes sense after the second feature, and the background work that has to finish whether or not anyone is watching it.
The pipeline around it
One command to deploy, a build that refuses rather than ships when a check fails, certificates that renew and are watched from somewhere other than the host doing the renewing, and alerts pointed at what a visitor would notice rather than at what is easy to graph.
Device to dashboard
Where the data starts at a device rather than at a form: the payload decoder, the backend the uplinks land in, the database that keeps them and the app somebody runs the operation from. The case study for that chain states, stage by stage, who did what.
Automation between systems
The glue a business already needs: n8n, Zapier or Make where a low-code flow is honestly enough, and code where it is not — webhooks, queues, retries, and the idempotency that stops a retry becoming a second invoice.
Controls underneath, where a building is part of the system
The same work with a building automation system in the middle of it, which is the rest of this site. A dashboard over a plant room is a web job sitting on a controls job, and the controls half is where it usually goes wrong.
The checks, as a deliverable
This site is generated by one script and gated by another: the second reads the built HTML and refuses the publish on a dead internal link, a contents entry pointing at nothing, or a claim that cannot be defended. How this site is built has the numbers, both gate runs, and the two accessibility defects that measurement found here. The same idea ports to any build, and it is the cheapest thing on this page.
Four things anyone can measure from outside
None of these needs access to your repository, your host or your analytics, and each one has a note under it that answers it in full whether or not you ever send an email:
- Plain http that stays plain http. A host that serves https does not necessarily redirect port 80 to it — what a plain-http request actually does, and the one-line fix per platform.
- A certificate nobody is watching. The expiry is in the handshake, so it is readable from anywhere — how to read it yourself, and the four ways an automated renewal still fails.
- An asset still requested over http. Script and stylesheet are blocked outright on an https page — what the browser does with each kind, and how to find every one in your own markup.
- A link on your own page that answers 404. Both ends are in your own repository, so it is checkable before a visitor finds it — the check, and why "it works locally" misses it.
The fifth is a line that is missing rather than a defect: the viewport meta tag, without which a phone lays the page out at desktop width and scales the result down.
A measurement is not a redesign. If one of those is true of your site, what arrives is the measurement and the note that answers it, not a proposal to rebuild anything. Most of them are a one-line fix somebody on your side can make this afternoon, and saying so is cheaper for both of us than a meeting.
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 thing itself | Front end, backend, schema and jobs, in a repository you own, with the dependencies named and pinned and a README somebody else can start from. |
| A deploy that is one command | Build, check, publish, and a way back — with the check running before the publish, so a failure is a build that stopped rather than a page that is wrong. |
| The certificate and the redirect, settled | Plain http redirected once with the right status, the certificate renewing, and the renewal watched from outside the host that renews it. |
| A check over the built output | Internal links, fragments, assets, mixed content and the viewport line, run in CI against what is actually published rather than against a dev server. |
| A short operating note | One page. How to deploy it, what the checks refuse and why, and what to do on the morning something fails. |
What it costs
A first job is a fixed 750 USD
That buys one to two days: the certificate chain, the plain-http redirect and every internal 404 fixed at the source rather than handed back as a list, or one deploy made repeatable from a clean checkout. The scope is written down before anything starts and it says what is not included. Past about three days it is not a first job any more: it gets its own written scope and its own number, quoted before work begins. No hourly billing, nothing to sign monthly, and no introductory rate. Scope a job.
After the job
Support afterwards is part of the offer
A deploy is the start of the life of a thing, not the end: a dependency bump, a certificate renewal nobody is watching, and an answer when a build fails at seven in the morning. How support works.
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 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.
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.
Spreadsheets & internal tools
An audit of the spreadsheet a team runs on — every rule it encodes, and which ones contradict each other — then one bounded slice of it as a web app.
Notes
Written up in more detail
The engineering behind this service, in public, with no pitch attached. All notes.
The http redirect a static host does not add for you
A host that serves https does not always redirect plain http to it. What a plain-http request really does, and the one-line fix on four common hosts.
- https
- Static hosting
- Deployment
The certificate renewal nobody is watching
Read notAfter off the handshake yourself, learn the four ways an automated renewal still fails, and monitor the certificate a visitor is actually served.
- TLS
- Certificates
- Monitoring
What a browser does with http assets on an https page
A stylesheet or script fetched over http on an https page is blocked outright. What a browser does with each kind, and how to find every one in your HTML.
- https
- Browsers
- Front end
A link check that runs before a visitor finds the 404
A link check over your own built output, in CI: the four classes of break it finds, and why it works locally and it worked last deploy both miss them.
- Deployment
- Front end
- Testing
The one line that decides how a phone renders a page
With no viewport meta tag a phone lays a page out at desktop width, scales it down, and matches no media query. What the tag changes, and what not to add.
- Mobile
- Front end
- CSS
What unused CSS actually costs a small site
A coverage audit calls over a third of this stylesheet unused. Across every page, 2.5% of it is. The gap is cache, and the real waste was in the head.
- CSS
- Performance
- Static hosting
What a spreadsheet rewrite actually costs
108 published workbooks, 464,872 formula cells: 99.1% translate mechanically. The cost is the 58.7% of columns computed two ways.
- Spreadsheets
- Web apps
- Measurement
Next step
Send the address. What comes back is a measurement.
Not a proposal: whichever of the four things below is actually true of the site, with the command that shows it and the note that answers it. If nothing is wrong, that is the answer and it is still free — this check finds nothing on a site that is fine, including ours.