We say when the brief is wrong
If we think the scope is solving the wrong problem, you hear it before the quote. It costs us work occasionally. It costs you far more to find out in month three.
Process
How We Work
How a project runs from the first call to handover, and what you hold at the end of each stage. Where we think a brief is solving the wrong problem, you hear it before the quote rather than halfway through the build.
The stages
-
Scoping
We work out what the software has to do, what it has to survive, and what would count as it working. Most of this stage is questions. The useful ones are usually about volume, existing systems and who owns the result.
What you get
- A written scope, in plain language
- The technical approach, with the trade-offs stated
- A cost range, with the assumptions it depends on
- Anything we think is wrong with the brief
-
Architecture
Data model, stack and service boundaries decided and written down before application code exists. These are the decisions that become expensive to reverse once there is real data in production, so they are made deliberately rather than discovered.
What you get
- The data model, documented
- Stack choices with the reasoning behind each
- Integration contracts for anything you already run
- A build plan broken into shippable pieces
-
Build
Shipped in working increments you can use and react to, rather than approving documents for three months and seeing software at the end. Tests are written alongside the code, not promised for later.
What you get
- A working environment you can open, from week one
- Regular releases you can use and comment on
- Tests that run on every change
- A changelog of what moved and what is next
-
Launch and after
Deployment, monitoring, and the handover your next developer will need. Launch day is planned at a quiet hour and watched, not fired and forgotten. Most of our work comes from clients we launched years ago.
What you get
- Deployment automated and documented
- Monitoring and alerting, with someone named on call
- Handover documentation written for a stranger
- Accounts and code registered to you, not to us
How we work, stated plainly
Scope changes are priced, not absorbed
Changes are expected on any real project. We price them as they come up rather than quietly swallowing them, so you always know what a change costs before we make it.
You own everything from day one
Code, accounts, domains and credentials are registered to you as they are created. Leaving should never be a project, and any agency vague about this is telling you something.
We write for the next developer
Documentation and a readable codebase are part of the deliverable, not a favour at the end. The test is whether someone who has never spoken to us can pick it up.
No fixed timeline before scoping
A delivery date quoted before anyone has seen the data is a guess dressed as a commitment. We give you a date once we know what we are building.
The people who scope it build it
You are not handed to a different team after signing. The engineers in your scoping call are the engineers on the project.
Ready to start at stage one?
Scoping is where we work out what the software has to do and what would count as it working. It is also where we tell you if the brief needs changing.