→ run --pipeline
01 discovery
02 scoping (fixed fee)
03 design
04 build
05 qa
06 launch
07 iterate
✓ every phase ends in a written artefact
// methodology
Nothing is built from a decision nobody wrote down.
Seven phases, each with named inputs, named outputs, a named owner and a duration. You can hold us to it, because it is written down before we start.
The pipeline
Discovery and scoping are a separate, paid, fixed-fee phase. That is what makes the rest of the price possible.
Discovery
Understand the problem, the constraints and the risks. Output: a written problem statement and a candidate scope.
Scoping
Turn that into a signed scope with acceptance criteria, a fixed price and a milestone plan.
Design
Wireframes, high-fidelity screens, tokens, components and a prototype - checked for buildability before sign-off.
Build
Implementation on a branch per piece of work, in your repository, with a demo you can attend.
QA
Every acceptance criterion tested, every defect closed or documented, on the device matrix that matches your users.
Launch
Production deploy, TLS, redirects, verified analytics, and a rollback plan written before launch day.
Iterate
Measure, decide, improve. A written read each cycle on what moved and why.
Each phase in detail
Inputs, outputs, who does the work and how long it takes. Durations are ranges because scope is the thing that varies.
| Phase | Inputs | Outputs | Who does it | How long |
|---|---|---|---|---|
| 01 Discovery | Your brief, access to existing systems and repositories, and the time of whoever actually owns the decision | A written statement of the problem, the constraints, the risks, and a candidate scope with what is explicitly excluded | Tech lead, with the strategist running interviews | 1 to 3 weeks |
| 02 Scoping (fixed fee) | The discovery output | A signed scope: in-scope list, out-of-scope list, acceptance criteria, architecture decisions, fixed price and milestone plan | Tech lead | 1 to 2 weeks |
| 03 Design | The signed scope, plus your brand, content and any existing design system | Wireframes, high-fidelity screens, a token and component set, and a clickable prototype | Designer, with the tech lead reviewing buildability before anything is signed off | 2 to 6 weeks, scaled by screen count |
| 04 Build | Approved designs and the signed scope. Nothing is built from a decision that was never written down | Working software in a staging environment, in your repository, on a branch per piece of work | Engineers reporting to one tech lead | 4 to 20 weeks depending on scope |
| 05 QA | A feature-complete build and the acceptance criteria from the scope | Test results against every acceptance criterion, cross-browser and device checks, performance and accessibility checks, and a closed defect list | Engineers plus a dedicated QA pass; the designer checks visual fidelity | 1 to 3 weeks, running alongside the tail of the build |
| 06 Launch | Your go decision, plus domain, hosting and third-party account access | Production deploy, DNS and TLS in place, redirects, analytics and error tracking verified, and a rollback plan on paper | Tech lead and the engineer who owns the release | A few days to one week |
| 07 Iterate | Analytics, search data and real user feedback | Measured improvements, a written read on what moved and why, and the next set of hypotheses | Growth and engineering, together | Ongoing, as a retainer or as agreed sprints |
Roles are named rather than people. The engineer who leads your project may differ from the one who wrote the scope; who holds which role is confirmed in writing at kickoff.
Definition of done
Vague completion is how fixed-fee projects go wrong. This is the checklist we hold ourselves to before anything is called finished.
| Condition | What it actually means |
|---|---|
| Acceptance criteria met | Every criterion in the signed scope is demonstrated in the staging environment, not asserted. |
| Reviewed by someone else | No change reaches production without a review by an engineer who did not write it. |
| Defects closed | No open critical or high-severity defect at launch. Medium and low are documented with a plan. |
| Agreed browsers and devices | Tested on the device and browser matrix agreed at kickoff, which is your audience, not ours. |
| Performance and accessibility | Measured against the budget set in the scope, with results in the handover notes. |
| Instrumentation verified | Analytics, error tracking and forms verified in production, not only in staging. |
| Documentation current | Setup, deployment and operations notes match the code as shipped. |
| Shown to you | You have watched it work. A demo is part of done, not a sales step afterwards. |
Note what is deliberately absent: a target number of revisions, and a percentage of the budget we decide to spend. Neither belongs in a fixed fee. Quality is a condition, not a line item.
Code review and handover
The part clients ask about least and regret most if it is weak.
Nobody merges their own work
Every change is reviewed by an engineer who did not write it. Reviews cover correctness, security basics, performance, accessibility and whether the code will still make sense in a year.
Readable history
Branching, commit and review conventions are agreed at kickoff and kept. A future developer reads the repository to understand why a decision was made.
Your accounts, your code
The repository, the domains, the hosting and the third-party accounts are yours from the start. We work inside your accounts rather than holding credentials in ours.
A handover package, not a verbal tour
Repository access, a setup guide, a deployment runbook, a third-party and credential inventory, and a list of known limitations with the reasoning behind each.
A live walkthrough
A session with the engineers who built it, recorded if you want it, going through the system the way a new joiner would. Questions are expected, not a formality.
Access ends cleanly
When the engagement closes, our access is revoked and you are told exactly what was removed. Nothing of ours stays in your systems by default.
Change requests and scope changes
A fixed price is only honest if the boundaries are explicit. Here is every category of change and how it is priced.
| Type of change | How it is handled |
|---|---|
| We misunderstood the scope | Our problem, not a change request. Fixed at our cost, with a revised date if the slip is material. |
| The scope is ambiguous and we clarify it | No charge. Clarifying our own written scope is part of delivering it. If the clarification shows the scope was materially wrong, the scope and price are reopened rather than argued about. |
| A genuine new requirement | Written change request with a description, an effort estimate, a price and a schedule effect. Approved before any work starts, invoiced as a milestone. |
| A small request nobody wrote down | Absorbed against the contingency named in the contract. There is no undisclosed buffer, and we do not run a hidden hours bank. |
| A change you need immediately | Possible, and priced at the priority rate set out in the contract. It is never free and it never quietly displaces other work. |
| You want to stop partway through | Contract terms set out what happens to work in progress and what handover looks like. Known before you start, not negotiated during a difficult week. |
The contingency allowance and the priority rate are set in your contract rather than advertised here, because a published allowance becomes a quota. Ask for both in writing with your proposal.
Walk through your project
Send the brief. We will map it against this pipeline and tell you which phases you actually need - some projects only need two of them.