Skip to content

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

Reviewed

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. 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:

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.

DeliverableDetail
The thing itselfFront 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 commandBuild, 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, settledPlain 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 outputInternal 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 noteOne page. How to deploy it, what the checks refuse and why, and what to do on the morning something fails.

Also

Other services

Notes

Written up in more detail

The engineering behind this service, in public, with no pitch attached. All notes.

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.