Spec in, system shipped, kept alive.
How custom engineering work is delivered here — not the WordPress pipeline. No Figma, no agency staging, no marketing cutover. A spec or a repo comes in; a working system goes out and stays running. Below, in the order it actually happens.
Not a website pipeline — a system that has to run.
The WordPress process is built around a launch. Engineering work is built around staying alive afterwards, so the shape is different at every step.
The intake is a repository, an architecture doc, or a written spec — not a Figma file and a sitemap workbook. The build runs on your infrastructure or ours, not a shared agency staging host. Verification is load and failure testing on real data volumes, not a Site Checker pass. And going live is a reversible, monitored deploy with a runbook — not a one-time marketing cutover. The white-label WordPress pipeline lives on its own page: Process (WordPress).
What carries over: fixed-hours estimates, async-first communication, and the rule that whoever wrote the code keeps maintaining it.
-
01
Intake: repo, spec, access
We start from the actual system — a repository, an architecture doc, the slow query, the access to a staging or read replica. If we're inheriting legacy, the lead reads it personally before proposing anything.
-
02
Estimate in fixed hours — prototype the risky part first
Scope is quoted in fixed hours against a written spec. Anything whose viability is unproven — an AI feature, a new data source, a load assumption — gets a prototype on your data before the bill, so the budget is set against a working thing, not a guess.
-
03
Build on your infrastructure or ours
Queues, replicas, proxy rotation, containers — built on whichever infrastructure the system already lives on, or on ours when that's cleaner. The architecture is chosen so the way data is fetched can change without touching the schema or the accumulated data.
-
04
Test under real load and failure
Verification is not a checklist pass — it's the system surviving real data volumes and the failure modes that actually happen: a source that bans you, a query that goes past the index, a registry that swaps its format. We reproduce those before go-live, not after.
-
05
Deploy with a runbook, reversible and monitored
Going live is a controlled, reversible deploy with monitoring and alerts wired into the working chat from day one — documented so a migration can be followed step by step. A recent infrastructure move shipped against a hundred-plus-page migration document.
-
06
Keep it alive — retainer and incident response
After go-live the system runs on a retainer: small fixes batched, larger work estimated separately, incidents answered in minutes to overnight with a written report. Whoever built a part maintains it years later — no context re-learned at every request.
Have a system to
build or rescue?
Send the spec, the repo, or the part that keeps falling over. Within a day: a sharp set of questions and an honest read on scope, risk, and what to prototype first. NDA on request.