How we build software
Senior engineers lead every build, from the specification to the release.
- You agree the specification
- Engineers build the change to the specification
- A senior engineer reviews each change
- Automated tests must pass
- An engineer releases it
The four phases of a software project
Specification-first development is building software from a written specification you have agreed, and letting no change ship until a senior engineer has reviewed it and the automated tests pass.
Quantum Craft is a software and AI development agency in London.
Last reviewed
A team builds what the specification says, mistakes included, so the specification gets the same care as the code.
Discovery and specification
One to two weeksWe work through the product with you and write it down: user flows, acceptance criteria, architecture, estimate and risks. You agree it before any code is written, and you keep it whoever builds.
- You get
- the written specification
Gate: Specification agreed, by you
Kick-off
First week of the buildRepositories, environments, the test pipeline and a milestone plan, all working before any feature code. The code can sit in your own repository from the first commit.
Gate: Tests in place before feature work, by an engineer
Build
Two-week cyclesEach cycle ends with a demo of working software, the test results and a note of decisions and open risks, so you judge progress by using the product.
Gate: Every change reviewed and tested, approved by a senior engineer
Launch and handover
Final cycleRelease to production, performance and security checks, then documentation another team could work from.
Gate: Released by an engineer
Who decides what on a build
Specify
You: agree the specification
Engineers: write the acceptance criteria and choose the architecture
Build
Engineers: build the change against the specification and decide what must be tested
Review
Engineers: a senior engineer reads each change and its tests
No change merges until a senior engineer approves it
Test
Automated tests: run on every change; a failing build does not ship
Release
You: use each demo
Engineers: merge after review and passing tests, and run every release
| Work | Who decides |
|---|---|
| Specification | A senior engineer agrees scope with you and writes the acceptance criteria |
| Architecture | A senior engineer chooses, and records why |
| Code | Engineers build each change to the specification; a senior engineer approves it before it merges |
| Tests | Engineers choose them from the acceptance criteria; they must pass before a change merges |
| Merges and releases | An engineer merges after review and passing tests, and runs every release |
| Production and client data | An engineer operates production and decides who sees what |
Seven commitments you can hold us to
Specification first
Nothing is built until the specification is written down and you have agreed it.
AI under business terms, and never in production
Any AI tool we use works on your code only through business accounts whose terms bar training on it. It never holds production credentials, and client personal data stays out of it.
Senior review on every change
A senior engineer reviews every change before it is merged.
Automated tests on every change
Automated tests run on every change. A failing build does not ship.
Decisions written down
Decisions are written down with their reasons, so the next engineer, yours or ours, can follow them.
The code is yours
The code we write for your project is yours on full payment, and it is documented so a competent team can run it without us. Our own tools and methods stay ours.
UK hosting when your data needs it
We built BlueWave and Karu for Google Cloud's London region, and your product can be hosted there too.
Your build, held inside the seven commitments, numbered as the list above: the specification goes in and a checked change comes out.
- 1. Specification first
- 2. AI under business terms, and never in production
- 3. Senior review on every change
- 4. Automated tests on every change
- 5. Decisions written down
- 6. The code is yours
- 7. UK hosting when your data needs it
What evidence do you get?
Three records, kept as the work happens rather than written up at the end. A technical due diligence reviewer will ask for all three.
The specification
What was agreed before anything was built, including the acceptance criteria each feature is tested against.
Illustrative sample, not a client record Specification extract Feature Acceptance criteria Decision owner Export my data A CSV download link arrives by email Product owner Archive a client record The record leaves every list and stays retrievable by an administrator Product owner Decision records
Each architecture decision, the options considered and the reason one won.
Illustrative sample, not a client record Decision record
- Context
- Users need to export their data.
- Options
- Generate on request, generate nightly, stream.
- Decision
- Generate on request and email a download link.
- Why
- Exports are rare and large; a nightly job would waste runs.
Test results
A test run for every change, including the one that shipped.
Illustrative sample, not a client record Test run
- Unit testsPassed
- End-to-end testsPassed
Merge allowed: yes
The three records, kept as the work happens: the specification, decision records and test results. A technical due diligence reviewer will ask for all three. Highlighted station: the reviewer.
If you are raising, the technical due diligence checklist shows where investors use each record, and seven red flags that stop a funding round shows what missing ones cost.
£4,500 for one week
Vibe coding vs engineered software
The difference is who answers for the code, and what is on record afterwards.
Vibe coding is building software by prompting an AI tool and shipping what it produces without anyone reading the code or taking responsibility for it.
| Question | Vibe coded | Engineered, as we work |
|---|---|---|
| Who writes the specification? | Nobody; the prompt stands in for it | Engineers, agreed with you before any code exists |
| Who answers for each change? | Nobody; the tool produced it | A senior engineer, who reads it before it ships and is on the record |
| Automated tests | Rare | On every change; a failing build does not ship |
| Evidence for technical due diligence | Little; nothing records what was decided or why | Specification, decision records and test runs |
| Where it fits | Demos and experiments you will throw away | Products you will sell, raise on or put regulated data through |
| Weak spot | Security, data isolation and maintenance | Slower than a vibe-coded demo to the first screen |
Two ways to build, one rail each, as the table below compares them. Vibe coded, the three gates are dashed: nobody writes the specification, nobody answers for each change, and tests are rare. Engineered, as we work, they are solid: engineers write the specification, a senior engineer reads each change, and tests run on every change. Highlighted station: the senior review.
- 1. Who writes the specification?
- 2. Who answers for each change?
- 3. Automated tests
- Iron mark: a senior engineer reviews every change before it is merged.
Who owns the code?
Ownership passes to you on full payment, and the code can sit in your own repository from the first commit if you want it there, so the history is yours as well.
We write the documentation as we build. Left to the final week, it turns into a summary of whatever people still remember.
Leaving should be dull. If you take the work in-house or to another supplier, they start from the same specification, decision records and tests we worked from, and nobody has to guess what we meant.
What we build with
- Web
- Next.js
- React
- Tailwind CSS
- TypeScript
- Mobile
- Android
- Flutter
- iOS
- Backend
- .NET 8
- FastEndpoints
- FusionAuth
- Data and search
- Elasticsearch
- MySQL
- PostgreSQL
- Python
- Redis
- Cloud and infrastructure
- Amazon Web Services
- Docker
- Google Cloud
- Google Cloud Storage
- Google Pub/Sub
- Kubernetes
- Microsoft Azure
- Payments, video and maps
- LiveKit
- Mapbox
- Stripe
- Stripe Connect
- AI in products
- AI assistants
- Document extraction
- Evaluation harnesses
- LLM integration
What we need from you
Most builds that slip are waiting for an answer.
A decision owner
One person who can agree the specification and make scope calls without convening a committee.
Access
To the systems we integrate with, test accounts and existing code, before the build starts rather than halfway through.
Test users
A few real users who will try each fortnight's build. Confusion found in week four costs far less than confusion found after launch.
Response times
Answers to blocking questions within two working days. We will always say which questions are blocking.
How are engagements priced?
Fixed price when the work is understood, time and materials when the problem is still moving, and a retainer for work after launch. Most engagements begin with one of four first steps, each with a published fee.
Pricing has every fee, the build bands, the engagement models and what takes the risk out of a first step.
Questions about how we work
Do you use AI tools on our code, and who checks the work?
We use AI tools only through business accounts whose terms bar training on your code. They never hold production credentials, and client personal data stays out of them. A senior engineer reviews each change before it merges, and the automated tests run on every one, so a failing build never ships.
Who owns the code you pay for?
You do. The code we write for your project is yours on full payment, as our terms set out. Our own tools and methods stay ours, and the code does not need them to run.
Is specification-first development just waterfall?
No. A specification covers the piece of work in front of us, and the build runs in two-week cycles you click through, so what you learn in week four changes week six. What we keep from the old way is agreeing things in writing before code exists, because a team given a vague brief will build the vague version.
2 more questions
Can our own team keep working this way after handover?
Yes. The specification, decision records and tests stay with the code, and they carry most of the method. Your team can use whichever tools it trusts, provided the gates stay: review before every merge, and tests on every change.
Freelancer or agency for a software build?
A freelancer is often cheaper and quicker to start with. An agency is easier to rely on if the product grows or one person becomes unavailable. With either, ask for the repository and the hosting accounts in your name from day one, regular demos, documentation and a written handover. A specification you own lets you take the work to any supplier. Our specification sprint costs £4,500 for a single workflow over one week and is yours to keep.
Tell us what you're building or deciding.
Tell us about a product you want built, or a decision about AI you need to make, and we'll set up a 30-minute call. You'll get a straight answer on what it would take.
What happens after you get in touch
We reply within one working day
By email, to arrange a time for the call.
A free 30-minute call
With a senior engineer, about what you are building or deciding.
The fee in writing first
If a first step is worth taking, you get its exact fee in writing before any work starts.