Skip to content
TrivialWorksTrivialWorks home

How we build

The delivery model, in full.

Most agencies added AI to the marketing page. We rebuilt the pipeline. This is what happens between your requirements and your production deploy — including the parts where we say no.

See the six stages Get a free functional spec
Stage 04 · Senior reviewhuman gate

Every generated diff leaves this stage as exactly one of three things. Two of them are a no.

  • Merged

    Correct, and it fits the code around it.

  • Sent back

    Plausible, and wrong. Regenerated against a tighter spec.

  • Thrown away

    The wrong approach. No amount of review fixes the shape.

Nothing reaches your main branch without a named engineer taking responsibility for it.

Six stages. Two of them are humans saying no. This is the actual delivery loop, not a diagram drawn for a website. Every change to your product passes through all six, in this order, every time.

  1. Blueprint

    agentSpec

    Your requirements become a structured spec with explicit acceptance criteria and edge cases, before a line of code exists.

  2. Forge

    agentGenerate

    Services, schemas, endpoints and UI are generated against the spec — with the existing codebase's conventions as context, not from a blank file.

  3. Redline

    agentMachine review

    Every diff is reviewed for security, performance, dependency risk and standards drift before a human ever opens it.

  4. Senior review

    human gate

    An engineer who has shipped production systems for two decades decides what is correct, what is plausible-but-wrong, and what gets thrown away.

  5. Proof

    agentTests & evals

    Test suites are generated and run against the acceptance criteria from stage 01. AI features get eval sets, not vibes.

  6. Ship

    human gate

    Release is a human decision, on a pipeline with automated rollback. You approve what goes to production.

6 stages · 2 of them a human saying no

The problem is not that the code looks wrong. It is that it looks right. Every example below compiles, reads correctly and passes the test written for it. A linter will not catch one of them, and neither will coverage.

  • Concurrency

    Check the row, then write it in a second statement. Two customers who click at the same moment both pass the check. Tests run one request at a time, so it goes green.

    • compiles
    • tests pass
    • correct
  • Authorisation

    A query filtered by record ID and not by tenant. Correct for the developer who is logged in, and it returns every other customer's row to anyone who knows an ID.

    • compiles
    • tests pass
    • correct
  • Scale

    A query with no bound on it, written against a table that has forty rows today. It is fine for a year, and then it is an outage on the morning you get busy.

    • compiles
    • tests pass
    • correct

The homepage carries one of these as a real diff, caught at stage 04 — the generated version and what came back.

We didn't buy an AI workflow. We built one. Four internal agents run inside the loop — Blueprint, Forge, Redline and Proof. They are ours: tuned on our standards, our review history and fifteen years of what we have learned not to do.

TW/Blueprint

Requirements → structured build plan

Turns founder conversations and RFP documents into a specification with acceptance criteria, data model and open questions surfaced up front — where changing your mind is still free.

Ambiguity caught before build

TW/Forge

Spec → working services

Generates services, schemas, migrations and interfaces against your existing codebase conventions, so output looks like the code around it rather than a foreign body.

The predictable 70%

TW/Redline

Adversarial diff review

Reads every change looking for injection paths, auth gaps, N+1 queries, unsafe dependencies and silent behaviour changes. It is tuned to be pessimistic on purpose.

Runs before any human review

TW/Proof

Tests, evals and regression

Writes and maintains the test suite against stage-01 acceptance criteria, and builds eval sets for any LLM-backed feature so quality is measured, not asserted.

Coverage that maps to requirements

Two of the six are a person. Everything else in this pipeline can be repeated, parallelised and run overnight. These two cannot, and that is deliberate — they are the stages where the work stops and waits for someone accountable.

04

Senior review

An engineer who has shipped production systems for two decades decides what is correct, what is plausible-but-wrong, and what gets thrown away.

06

Ship

Release is a human decision, on a pipeline with automated rollback. You approve what goes to production.

That loop runs inside a 19-phase lifecycle. The six stages are what every code change passes through. Around them sits the whole engagement — concept, requirements, feasibility, architecture, design, testing, release, documentation, training and support. A senior engineer owns each phase and signs it off before the next begins.

  1. 01

    Define

    4 phases

  2. 02

    Plan

    2 phases

  3. 03

    Design

    3 phases

  4. 04

    Build

    3 phases

  5. 05

    Verify

    2 phases

  6. 06

    Release

    3 phases

  7. 07

    Sustain

    2 phases

  8. All 19 phases

AI writes code. It does not decide what ships. The reasonable objection to AI-first development is that it produces plausible garbage at high speed. It does — if nobody is qualified to catch it. Here is what we hold fixed.

  • A senior engineer signs off every change

    No generated code reaches your main branch without a named human who has shipped production systems for two decades reading it and taking responsibility for it.

  • You own the code and the IP outright

    Assigned to you in the contract, in your repository and your cloud account from week one. There is no platform to be locked into and nothing to buy back.

  • Your code is not training data

    We use commercial API tiers with training disabled. Your repository, your data and your customers' data are never used to train anyone's model.

  • Security review is not optional

    Automated adversarial review on every diff, dependency and secret scanning in CI, and a documented threat model for anything handling money, health or identity.

  • Tests are generated but verified

    A test suite written by an agent that only proves the code does what it already does is worthless. Ours are written against the acceptance criteria agreed in week one.

  • We tell you when AI is the wrong answer

    Some problems want a database query and a well-designed form, not a model. We will say so — including when it costs us the larger engagement.

Send us something to look at.

A requirement in whatever shape it is in, and you get back a functional specification — screens, data model, stack and an estimate. No charge, and no obligation to build it with us.

Send a brief info@trivialworks.com