Every agency says they are collaborative, agile and transparent. Those words cost nothing. This page describes what actually happens, in order, including the parts that are uncomfortable.
We publish this because process is the thing you are really buying. Any competent firm can write code. What separates them is what happens when the estimate was wrong, when the integration does not work, and when you want to change something halfway through.
Week 0 — The qualification call
45 minutes, free, no proposal attached.
We are trying to establish three things:
- What the problem costs you today — in hours, errors, lost sales or risk. If you do not know, we will work it out on the call. A problem with no cost attached does not justify a build.
- What building it would be worth. We calculate the payback with your numbers on the call — annual cost of the problem against build cost and running cost.
- Whether the numbers can work. Our minimum build engagement is £10,000. If your budget and the realistic cost do not overlap, you should know on the first call rather than after three meetings.
You leave with a number and a payback period. That is what the call is for.
What we will not do on this call: present slides, demo unrelated work, or ask for your budget before telling you what things cost. Our prices are published.
Weeks 1–2 — Discovery
£3,000–£8,000 depending on complexity. ERP process mapping runs £6,000–£15,000.
Discovery is not a formality before the real work. It is the work that determines whether the rest succeeds.
What we actually do:
- Map the real process, not the documented one. These differ, always. We talk to the people doing the job, not only the people who commissioned the project.
- Connect to every system that needs integrating. Not “confirm an API exists” — actually authenticate against it and read data. This is the single most valuable thing in discovery.
- Look at your real data. A sample export tells us whether migration is a day or a month. Guessing here is how projects go 50% over.
- Identify who decides. A project with one decision-maker moves at the speed of the build. One needing four departments to agree moves at the speed of the slowest calendar.
- Write down what we will not build. The boundary matters more than the feature list.
What you get: a requirements document, a technical approach, a costed plan with phases, and a written build-or-buy recommendation.
It is yours. If you take the discovery output to another supplier and they build it cheaper, that is a legitimate outcome. We will not make it awkward and we will not withhold anything. A discovery document you cannot take elsewhere is a hostage, not a deliverable.
Why discovery is paid
Free discovery is paid for somewhere — usually in a padded build price, or by a sales process designed to make leaving expensive. Charging for it means we can tell you not to proceed without having lost money, which is the only way that advice can be honest.
The build — in reviewable stages
Work is divided into stages of roughly two to three weeks. At the end of each, you see working software, not a status report or a percentage.
What a stage contains: an agreed set of functionality, built, tested and deployed somewhere you can use it.
What happens at the end of a stage: you use it. You tell us what is wrong. We fix what we got wrong at our cost, and quote anything that is genuinely new.
The distinction matters and we apply it consistently:
| Who pays | |
|---|---|
| We built something that does not match the agreed spec | We do. That is a defect. |
| We misunderstood something and built the wrong thing | We do. Our job was to understand. |
| You have changed your mind, or learned something new | You do — quoted before the work starts, never invoiced after. |
That third row is normal and expected. Projects that learn nothing during the build were not worth doing. What is not acceptable is discovering the cost afterwards.
When we are wrong
Every project of any size contains at least one wrong estimate. Here is what happens when it is ours.
On fixed price: the overrun is our problem. You pay the quoted figure. This is the point of a fixed price and it is why fixed prices are only available after discovery.
On time-and-materials: you get a revised estimate before the additional work is done, with the reason and the options — including doing less. You are never presented with an invoice for work you did not know was happening.
If we are badly wrong: you will hear it the week we know, not at the end. The commercial conversation that follows is unpleasant for us and survivable for you. The alternative — quiet absorption until the deadline arrives — is how projects fail catastrophically rather than expensively.
Testing and quality
Automated tests on business logic. Not on everything — testing a layout is theatre — but on the rules that move money, allocate stock, calculate prices or control access.
We test before you see it. You are not the first person to run the feature. Finding obvious faults is our job, and sending you work we have not used ourselves wastes your time.
Security as part of the build. Input validation at trust boundaries, proper authentication, least-privilege access, dependencies kept current, secrets never in source control. This is not an add-on line item.
Accessibility as standard. Keyboard navigation, sensible contrast, proper labels and semantic markup. Beyond being the right thing, UK public sector and many enterprise procurement processes require it.
Handover
This is where most of this industry is weakest, so it is specified precisely.
You receive:
- Source code, in a repository you own
- Documentation — architecture, deployment, configuration, known limitations
- Deployment instructions that a competent engineer who has never seen the project can follow
- Infrastructure in your accounts, on your keys, under your billing
- Credentials and access to everything, held by you
All intellectual property assigns to you on final payment.
What we do not do: host your business on our platform, retain deployment access as leverage, licence back to you code you paid for, or write documentation so thin that leaving is impractical.
Ask every supplier you consider: “Do I own the source code outright, when does it transfer, and can another firm pick this up without you?” Get it in writing. A common and entirely legal arrangement in this industry is that the agency owns the code and licences it to you — which means leaving means rebuilding.
After launch
Support retainer — from £800/month (£1,200 for ERP, £1,500 for AI operations). Defined response times, monitoring, fixes and a monthly allowance of small changes.
Or ad-hoc. Quoted per change, no retainer.
Or nothing. You hold the code and the documentation. Taking it in-house or to another firm is a legitimate outcome we have designed for rather than guarded against.
Software is never finished. What matters is that continuing is your choice rather than your only option.
Payment structure
| Structure | Milestones against accepted deliverables |
| Typical schedule | 30% on signature · 40% at agreed midpoint · 30% on acceptance |
| Discovery | Paid in full up front — it is a complete deliverable in itself |
| Retainers | Monthly in advance, 30 days’ notice either side |
| Never | A large upfront sum with no deliverable attached |
Milestones tied to accepted deliverables are the protection. If a supplier wants half the money before anything exists, treat that as information.
What we need from you
Projects fail on the client side too, and the pattern is consistent. The three things that matter most:
- One decision-maker. Someone who can say yes without convening a committee. This affects cost more than almost any technical factor.
- Access to the people who do the work. Not only the sponsor. The person who actually processes the orders knows things the org chart does not.
- Responses within a few days. A project waiting on a decision is still costing money. We will tell you when something is blocking.
How we estimate
The method, so you can judge whether a number was thought about or guessed.
We break the work into pieces small enough to be wrong about cheaply. A two-day estimate that turns out to be four days costs two days. A twelve-week estimate that turns out to be twenty costs eight weeks.
We estimate the integrations first, because they carry the most uncertainty and they are the most common cause of overruns. Where an integration is genuinely unknown, we price investigating it rather than pretending to price building it.
We look at your data before estimating migration. Record count tells us nothing; quality tells us everything.
We add contingency explicitly, and say so. A fixed price contains a risk premium. Hiding it is standard practice; stating it means you can decide whether to pay for certainty or carry the risk yourself on a capped time-and-materials basis.
We do not pad silently. If the honest number is higher than you hoped, you get the honest number and the options for reducing it.
Communication
| Weekly | 30-minute video call — what shipped, what is next, what is blocked |
| End of each stage | Working software you use yourself, not a demo |
| Blockers | Raised the day they appear, not at the weekly |
| Bad news | The week we know, never at the deadline |
| Written summary | After every call, so decisions have a record |
| Escalation | A named engineer and a direct number, not a ticket queue |
What we will not do: send a percentage-complete report. “Seventy per cent done” is unverifiable and usually means the easy seventy per cent is finished.
What happens in the first two weeks
Concretely, so you know what you are buying when you pay for discovery.
Days 1–2. Interviews with the people who do the work, not only the people commissioning it. We are looking for the gap between the documented process and the real one, which exists in every business.
Days 3–4. Systems. We request credentials and actually connect — authenticate, pull real records, confirm the fields exist. This is the highest-value part of discovery and the part most commonly skipped.
Day 5. Data. A real extract, inspected: duplicate rate, null rates on required fields, format consistency, referential integrity. This produces the migration estimate.
Days 6–8. Options. Usually two or three approaches at different price points, including the option of buying something instead of building.
Days 9–10. The written output — requirements, technical approach, costed plan by phase, and a build-or-buy recommendation. Delivered and walked through.
Then you decide, with no pressure and no expiry date on the quote.
Frequently asked questions
How long does a typical project take?
Discovery takes one to two weeks. A small system takes four to eight weeks. A mid-size platform takes eight to twenty weeks. A core business system takes twenty weeks or more.
Do I have to pay for discovery?
Yes. Free discovery is recovered elsewhere, usually in the build price. Paying for it means we can recommend against a build without losing money, which is what makes the recommendation worth anything.
Can I take the discovery document to another supplier?
Yes. It is yours, in full, including the technical approach and costings.
What if I want to change something mid-project?
Normal and expected. It gets quoted before the work starts. You will never receive an invoice for a change you did not approve.
What if the project runs over?
On fixed price, that is our risk and you pay the quoted figure. On time-and-materials, you get a revised estimate before the work is done, with the option of doing less.
Who owns the code?
You do, outright, assigning on final payment, with documentation and deployment instructions, running in your accounts on your keys.
Do you offshore development?
No. Development is UK-based. Offshore is a legitimate option and sometimes the right one — we will say so when it suits your situation better.
What happens if you stop trading?
You hold the source, the documentation and the deployment instructions, and the infrastructure is in your name. Another firm can continue the work. Ask every supplier this question.
How do you handle security?
Validation at trust boundaries, proper authentication and authorisation, least privilege, current dependencies, no secrets in source control. Built in, not quoted as an extra.
Can you work with our in-house developers?
Yes. Shared repository, agreed conventions, code review in both directions. We would rather leave your team more capable than more dependent.
What goes wrong, and what we do about it
Every project of size hits at least one of these. Published so you know the response before you need it.
An integration does not work as documented. We find this in discovery wherever possible, which is why we connect to systems rather than asking about them. When it surfaces mid-build, you get the options — work around it, change the approach, or descope that piece — with costs attached, before anything is done.
The data is worse than it looked. We quote migration separately after inspecting a real extract, so this is rare. Where it happens, we tell you the revised figure and the options, which usually include migrating less history.
A key person on your side becomes unavailable. Projects stall on client availability more often than on supplier capacity. We will tell you when a decision is blocking and what it is costing in elapsed time.
You want something materially different from what was agreed. Quoted before the work starts. Normal and expected — projects that learn nothing were not worth doing.
We underestimated. On a fixed price, that is our cost and you pay the quoted figure. You will hear about it in the week we know, because the alternative is a worse conversation later.
The project stops being worth finishing. Rare and it does happen. We will say so. That is what paid discovery buys — advice that can afford to be honest.
Next step
Written by Jas Singh, Founder. Last updated 8 October 2026.



