A prototype is evidence. Production is a commitment.

Decide explicitly what enters production

Cheap experiments test assumptions. They do not grant production authority. Before work enters the delivery path, we establish:

• a named outcome — which business or user result should change, who benefits and how, and how the organisation will measure success;
• evidence — the user need, operational problem, usage signal or prototype that supports it;
• product coherence — whether it strengthens or fragments the product, and which constraints and risks are material;
• a service owner — who can make product and release decisions, and who owns and supports the result.

Only work with an outcome, evidence, fit and an owner proceeds. A prototype informs the decision; it does not make it. Where a rapid or citizen-built prototype has already proved the need, we extract its intent into a reviewed specification and rebuild it as a supported service. This is not a demand for a giant specification. It is enough direction to stop fast implementation hardening a weak assumption.

Give builders clear intent

We turn the outcome into a first release with explicit intent, constraints and acceptance checks.

Product, design, architecture and engineering work together around it. Decisions do not disappear in hand-offs, and agents do not have to infer business rules from a thin ticket or a long chat transcript.

Unknowns stay visible. The right stakeholder resolves material ambiguity while the decision is still inexpensive to change.

Design for production from the start

The first delivery establishes the foundations needed for the life of the product: automated builds, tests and security checks; repeatable infrastructure and deployment; controlled release and recovery; observability; operational ownership; specifications and decisions that remain with the product.

Production is part of the design, not a hardening phase postponed until launch.

Let people and agents contribute safely

We use approved coding agents to accelerate research, specification, implementation, testing and review. Where domain experts contribute directly, we define what they can build, which data they can use and when engineering takes over.

Shared engineering controls carry those rules into editor configuration, agent instructions and pipeline checks, so the same rules apply whether the author is an engineer, a domain expert or a coding agent.

Our spec-driven development engine connects business intent and available evidence to reviewable specifications, then coordinates implementation and verification from those durable inputs.

We measure whether the result was actually faster and less expensive. Generated code is not evidence of value.

Release, observe and learn

Each delivery has a measurable purpose, reviewed intent, checks appropriate to the risk, a release approach, observability and a recovery path.

Feature flags and controlled exposure separate deployment from release. The team can validate real behaviour, limit impact and learn sooner — without making every deploy a business event.

Deliver on a known foundation

The software we build runs on our WebAssembly runtime. Because the host bridges external services and infrastructure, sandboxed Wasm guests contain business logic rather than plumbing — shrinking what coding agents have to generate and what engineers have to review.

Paired with a formal specification broken into bounded slices, each change requires far fewer tokens and can be built by smaller, cheaper models than generating an entire service from scratch. Reusable Terraform, GitHub Actions and environment patterns then carry that artifact to production.

The business problem is unique. The way the software runs and ships does not need to be.

See how we deliver

When this approach fits

This approach is valuable when a new system:

• is important to a business process, customer experience or public service;
• needs to reach production sooner without making release reckless;
• must be maintainable and operable for years;
• has material security, privacy or regulatory constraints;
• will change frequently as the organisation learns;
• needs a delivery foundation the client’s team can own; or
• would create significant cost or risk if the wrong assumptions were automated.

For a disposable prototype, the full practice may not be necessary. We match the safeguards to the stakes: give the prototype room to learn, and strengthen the safeguards as people come to depend on the system.

Begin with one change

Bring us the result you need, the people it matters to and the constraints you already know. We will shape a first production delivery that makes the next change easier.

Start a conversation See how each delivery improves the next