How we work

1. 01

   Discovery

   We work out what you are actually trying to build and what constrains it — traffic, team, deadline, existing systems, budget. Most of the value here is in what gets ruled out.

   Artifact: A written problem statement and constraint list

2. 02

   Architecture

   We choose a stack and a shape, and write down why, including the trade-off we made and what would change the answer. You keep this whether or not we build it.

   Artifact: Architecture document, stack decision with reasoning, risk register, build estimate

3. 03

   Build

   Shipped in reviewable increments against the agreed architecture. You see working software throughout, not at the end.

   Artifact: Working software, tests, and deployment pipeline

4. 04

   Handover

   Documentation written for whoever maintains this after us, including the parts we would do differently. If you never call us again, that should be a choice rather than a dependency problem.

   Artifact: Runbook, architecture notes, and a walkthrough with your team

Engagement models

What we do when we're wrong

One of our database engines, Lumen, used to advertise capabilities it did not have. An audit found several were stubbed or incorrect, and that its published test and benchmark figures were not reproducible.

We removed the claims, fixed every defect the audit surfaced behind its own test, and rewrote the README to say plainly that it is experimental, that performance has not been benchmarked on representative hardware, and that no throughput numbers are claimed.

That is the standard we hold everything to, including this site. We publish no number we have not measured.