How we run projects
This page exists to pre-answer half of every sales call. Each stage below lists what we do, what we need from you, how long it takes, and what exists at the end of it.
The seven stages
- 01 1–3 weeks
Discovery
A paid, fixed-price phase before any build commitment. We sit with the people who do the work, map the process as it really runs, and find the workarounds — because the workarounds are where the real requirements live. It ends with a written process map, a data model, a scoped build plan and a fixed quote. If you decide not to proceed, the document is yours to take to another vendor.
Output: Process map, data model, scoped build plan, fixed quote
We do
- Interview the people who do the work daily, not only the manager
- Map the current process including the informal steps
- Review existing systems, spreadsheets and data quality
- Design the data model and walk you through it in plain language
- Identify what should not be built, and say so
- Produce a scoped plan and a fixed quote
You do
- Give us two to four hours with the people who run the process
- Share a sample of real data — anonymised is fine
- Name one decision-maker who can settle scope questions
- 02 3–5 days
Proposal & fixed scope
We turn discovery into a proposal that states what is included, what is explicitly excluded, what it costs, and when each milestone lands. The exclusions matter as much as the inclusions — most project disputes are about something one side assumed was in scope. We would rather have that conversation now, in writing, than in month three.
Output: Signed proposal with milestones and payment schedule
We do
- Write the scope as testable statements, not adjectives
- List exclusions explicitly
- Break the work into milestones with payment tied to each
- State assumptions and the risks that could move the estimate
You do
- Read the exclusions carefully and challenge them
- Confirm the milestone order matches your priorities
- Sign off before we start — no work begins on a handshake
- 03 1–3 weeks
Design & architecture
The data model is the decision that is expensive to reverse, so it is settled first and reviewed with you before anything is built on top of it. Interface design happens here too — as clickable screens rather than static mockups, because a screen that is wrong is much cheaper to find now than after it is wired up.
Output: Schema, permission model, clickable prototype, integration plan
We do
- Finalise the schema, including the reporting queries it has to serve
- Design the permission model and the role boundaries
- Build clickable screens for the flows people will use daily
- Choose and document the integration approach for each third party
You do
- Walk the clickable screens with the people who will use them
- Confirm the role boundaries match how your team is actually organised
- Provide credentials or sandbox access for integrations
- 04 The bulk of the project
Build in two-week increments
Every two weeks something works and is deployed where you can use it. Not a status report — running software. That cadence exists because it is the only reliable way to find out that a requirement was misunderstood while it is still cheap to correct, and because it keeps the project honest about progress.
Output: A deployed increment every two weeks
We do
- Ship a deployed, usable increment every two weeks
- Demo it live rather than sending a document about it
- Keep a visible backlog with what changed and why
- Write tests around the logic that would be expensive to get wrong
You do
- Spend 30–45 minutes on each demo
- Give feedback within a few days — stale feedback costs more to apply
- Raise scope changes as they occur to you, not at the end
- 05 1–3 weeks
UAT
Your people use the system on real scenarios, in a staging environment with migrated data, against a written test plan rather than a vague invitation to "have a look". Issues are triaged into defects, which we fix, and changes, which get quoted — separating those two honestly is what keeps UAT from becoming an unbounded second build.
Output: Signed-off test plan and a triaged issue list
We do
- Provide a staging environment with your migrated data
- Write the test plan covering the flows that matter most
- Triage every issue as a defect or a change, transparently
- Fix defects inside the agreed scope
You do
- Nominate two or three people to test properly, with time allocated
- Test with real scenarios, including the awkward ones
- Accept that a change is a change — and decide whether it is worth it
- 06 3–7 days
Deployment
Go-live into your own cloud account, with infrastructure as code, a rehearsed data migration, and a documented rollback. We do the migration at least twice before the real one — a migration that has never been rehearsed is a migration that will surprise you on the day it matters.
Output: Live system, verified backups, trained team, recorded sessions
We do
- Deploy to your cloud account with infrastructure as code
- Rehearse the data migration, then reconcile the results with you
- Configure backups and verify a restore actually works
- Set up monitoring and error alerting
- Train your team and record the sessions
You do
- Provide cloud account access, or let us set one up in your name
- Reconcile the migrated figures against your current records
- Pick a go-live date that is not your busiest week
- 07 1 month included
Support & handover
The first month after go-live is when the requirements nobody articulated finally surface. It is included, not billed as an extension. After that you choose: a support retainer, or a clean handover with documentation and the source in your repository. Both are real options — we build so that leaving is possible, because a client who cannot leave is not a client who stays by choice.
Output: Documentation, runbooks, repository access, support decision
We do
- Included support for the first month after go-live
- Fix defects that emerge under real use
- Hand over documentation, runbooks and repository access
- Offer a retainer if you want one — no pressure if you do not
You do
- Route issues through one person so they are not lost
- Decide on retainer or handover before the month ends
Timelines
Realistic ranges by project size
These are ranges, not promises. The number that moves them most is how quickly decisions come back from your side.
| Project size | Discovery | Build | Total |
|---|---|---|---|
| Focused tool One workflow, one or two roles, minimal integrations | 1 week | 3–5 weeks | 4–6 weeks |
| Departmental system Several roles, real reporting, two or three integrations | 1–2 weeks | 6–12 weeks | 8–14 weeks |
| Core operational platform Multi-module, integrated with finance, business-critical | 2–3 weeks | 4–7 months | 4–8 months |
| Modernization programme Incremental extraction while the system stays in production | 1–2 weeks | Ongoing | 4–12 months |
The single biggest cause of overrun in our experience is not engineering — it is waiting for a decision. Every stage above names who needs to decide what, for that reason.
Before we start
What makes a project go well
None of this is unusual. All of it is worth agreeing before a contract rather than after.
- One decision-maker who can settle scope questions without a committee
- Access to the people who do the work daily, not only their manager
- A sample of real data, anonymised if you prefer
- Credentials or sandbox access for any system we must integrate with
- Two or three testers with time actually allocated for UAT
- A go-live date that is not in your busiest week
- Agreement that a change is a change, and gets quoted
- Willingness to hear that part of the plan is a bad idea
FAQ
Questions about how we work
Why is discovery paid?
Because free discovery is not discovery — it is a sales call with a diagram. Doing it properly means several days of interviewing your team, reading your data and designing a model, and work of that size is either paid for or done superficially. It is priced small deliberately, and the document is yours whether or not you continue with us. You can take it to another vendor and get comparable quotes against a real specification.
What happens if the estimate turns out to be wrong?
On fixed-scope work, the risk is ours — that is what fixed price means, and it is why we insist on discovery first. What is not covered is scope that grows: a new requirement is quoted and you decide whether it is worth it. The thing we will not do is silently absorb additions by cutting quality somewhere you cannot see.
How much of our time will this take?
Concentrated at the start and light after that. Discovery needs two to four hours with the people who run the process. During the build, roughly 30–45 minutes every two weeks for the demo. UAT needs two or three people with real time allocated, typically a few hours each across a week or two. Every stage on this page lists what we need from you.
Can we pause the project?
Yes, at any milestone boundary. Work is structured so each increment is deployable and each milestone is a natural stopping point. A project paused after milestone three leaves you with working software, not a half-finished system that does nothing.
What if we already have a specification?
We will read it and usually still recommend a short discovery — not to rewrite it, but to verify it against how the work actually runs. Specifications written internally tend to describe the documented process, and the gap between that and the real one is where projects go wrong. If it holds up, discovery is shorter and cheaper.
Do you sign NDAs?
Yes, before discovery starts, on your paper or ours. We also do not use client names, logos or details anywhere without written permission — which is part of why the work shown on this site is our own.
Start with discovery.
It is small, it is fixed-price, and the document it produces is useful to you whether or not we build the thing.
30 minutes · We reply within one business day.