What your build costs, before you pay us anything
The ranges are already published on this site, with a calculator that produces a figure for the build you are describing. No form, no call.
Talk to us about your build
Tell us what you are building and what it connects to. We come back with the shape of the phase and what it costs.
Take the range before talking to us
Cost bands and a calculator.
Three complexity bands for custom software, and a calculator that computes a figure from what you are describing. These are planning ranges, not a quote.
Web page · about 12 minutesRead it — Cost bands and a calculator.An RFP template.
The questions worth putting to any development partner, in a document you fill in and send out, including to people who are not us.
Web page · about 12 minutesRead it — An RFP template.
You have something you want built and no way to size it yet. Most firms will not give you a number until you have talked to them, and you cannot start that conversation until you know whether their work is affordable at all.
The first question is never about method. It is whether the whole thing is affordable at all, before you spend anything finding out.
That answer is already on this site and it is not behind a form. Three bands by complexity, and a calculator that turns the feature list you have in your head into a figure. These are planning ranges, not a quote. Take the number and the assumptions under it, and put both in front of whoever signs.
If the figure lands somewhere you can live with, the rest of this is about turning it into a number we will stand behind. If it does not, you have found that out today rather than after three meetings and a proposal. What we sell after that is a bounded discovery phase that turns a range into a number we will sign against.
What the overrun risk actually looks like
You will be quoted a lot of numbers about software projects failing. The one you will hear most often comes from a study nobody outside its paywall can check, so we do not use it, and it is worth asking anyone who does where they got it.
Here is a set that can be checked. Flyvbjerg and Budzier studied 1,471 ICT projects. About half came in with no cost overrun at all. About three in ten overran without becoming an extreme case. About one in six were what the authors call black swans, averaging close to 200% over budget.
Show data table
| Segment | Value (%) | Share |
|---|---|---|
| About half: no cost overrun | 53 | 53% |
| About three in ten: overran, not extreme | 30 | 30% |
| About one in six: extreme overrun | 17 | 17% |
The exposure you are sizing is a small chance of something you cannot absorb, sitting behind an average that looks calm.
That is what the questions asked before anyone writes code are for.
Sources: Why Your IT Project May Be Riskier Than You Think, preprint at arxiv.org/abs/1304.0265
Every kind of project has a typical case that lands on budget
The same research group looked at 4,677 IT projects across 66 countries, public and private sector, with both a budgeted and a final cost on record. Split by project type, the median project of every type came in at roughly what it was meant to cost. The averages do not sit anywhere near it: they run from 1.3 times budget for ERP work up to 2.2 times for supply-chain work. The distance between those two lines is the tail, and nothing else.
Show data table
| Dimension | Mean | Median |
|---|---|---|
| ERP | 1.3 | 0.9 |
| HRM | 1.5 | 1 |
| MIS | 1.8 | 1 |
| SCM | 2.2 | 1 |
| Other | 2.2 | 1 |
The median project of every type came in at roughly what it was meant to cost, while the means run from 1.3 to 2.2 times budget.
What matters for your build is your own exposure, and that is knowable before anyone writes code. What is in scope. What your system has to talk to. What the data model is. Those three are what the BRD, FRD, SRS and TRS sequence exists to pin down, and pinning them down is the work.
Sources: The Empirical Reality of IT Project Cost Overruns, arxiv.org/abs/2210.01573
What exists at the end of each stage
01
Requirements sessions
Your people and our business analysis team in the room, working through what the business needs.
You get
A business requirements document, the BRD: what the business needs the software to do.
02
Functional detail
Every screen, rule and user path written down and read back to you.
You get
A functional requirements document, the FRD: the behaviour of the system, screen by screen.
03
Specification
The system described the way the people who will build it read it.
You get
A software requirements specification, the SRS: the system written out in full, requirement by requirement.
04
Technical design
Architecture, integrations and the data model, with the decisions behind them written down.
You get
A technical requirements specification, the TRS: the architecture and the decisions behind it.
05
Milestones and risk
Scope broken into milestones with documented exit criteria, and the risks that would move the number.
You get
A milestone plan and a risk map: the milestones, their exit criteria, and the risks.
Nothing is put in front of you in language you cannot read. Every requirement document is reviewed in plain English with you before any code is written. If you arrive with mockups, we work from those, and high-level wireframes are part of the work when the budget includes UX work.
Each milestone has a documented exit criteria, and this phase is a milestone like any other. It ends on your decision about whether to build, not on the delivery of a report. The GOV.UK Service Manual describes a discovery phase the same way, and it treats stopping as a legitimate result.
Sources: GOV.UK Service Manual, how the discovery phase works, gov.uk/service-manual
What you own, and what happens if you leave
The documents are yours from Day 1. IP belongs to you from Day 1, code lives in your repositories, deployments in your cloud accounts, and architecture decisions are written down in the TRS.
If you choose to move the work in-house or to another partner, we will not obstruct the handover, and a handover comes with a written runbook. Our rule as a vendor is to empower the client, not lock them in. So far, no client has needed to use it.
Twelve firms' own discovery pages, read on 2026-08-30. The counts describe what those pages publish. No firm is named.
Twelve firms' own discovery pages, read on 2026-08-30. The counts describe what those pages publish. No firm is named.
Twelve firms' own discovery pages, read on 2026-08-30. The counts describe what those pages publish. No firm is named.
Twelve firms' own discovery pages, read on 2026-08-30. The counts describe what those pages publish. No firm is named.
We put that in writing before you ask, because the alternative is your own lawyer asking it three weeks from now, and a vague answer at that point reads as a trap and stops the conversation. If you are about to put this work to several firms, the RFP template is the set of questions worth asking all of them.
The terms, before you book a call
Discovery phase
Four to eight weeks, per GOV.UK
What it includes
- Bounded, not open-ended. Scoped to the depth your project's foundation needs, separately from the build.
- Nothing here obliges you to build with us.
- Whatever can start while deeper planning resolves, starts. Complex requirements take longer to plan, never longer to start.
- Execution begins once the scope is approved.
Widens when less of the foundation is already settled when the phase begins.
The GOV.UK Service Manual puts a typical discovery phase at four to eight weeks. That is the category's published figure rather than a commitment on your engagement, and how long yours runs depends on how much of the foundation is already settled.
We quote the fee against your actual scope on the call. A number published against a build we have not heard about yet would be wrong for most of the people reading it.
Book the call and we will scope the phase against what you describe.
Sources: GOV.UK Service Manual, how the discovery phase works, gov.uk/service-manual
When you should not buy this
Buy this if
You have a build in mind and no defensible number for it.
Several teams inside the business want different things from it.
Something has to connect to systems nobody has fully mapped.
Somebody senior has to approve a spend and will ask where the figure came from.
Do not buy this if
Your scope is already written down, the integrations are known, and you have a technical lead who can hold the specification.
Your engagement needs a vendor holding SOC 2, GDPR or HIPAA certification, which we do not hold ourselves.
You want the decision you have already made confirmed on paper, which is a document rather than a phase.
We are success partners, and we have declined engagements where taking them would have benefited us but not the project. Three situations where this phase is the wrong purchase.
Where the scope is already settled, you are buying build capacity rather than a plan. Where an auditor requires a certified vendor, we say so upfront and refer where appropriate. We build systems that pass your audits and document the design intent in the TRS. Paying for a document that confirms a decision you have already made is a poor use of your budget.
What to repeat to whoever signs
Five facts, in the order they get challenged. Forward them to whoever signs, and to anybody who asks where the figure came from.
Forward this part
Atyantik's discovery phase: the terms and what you own
- The range. The cost ranges and the calculator are published and ungated, and they are planning ranges, not a quote.
- The phase. The phase is bounded and scoped separately from the build. Nothing obliges you to proceed.
- The documents. The documents are yours from Day 1. If you move the work in-house or to another partner, Atyantik will not obstruct the handover, and a handover comes with a written runbook.
- The estimate. Atyantik's estimate is real once you sign off, and is not padded after.
- The end. The phase ends on the decision about whether to build, and stopping is a legitimate outcome of it.
Before you pay for a plan
What does a discovery phase cost?
Is it worth paying for a discovery engagement if the build turns out to cost ten times my budget?
What happens if we stop after discovery? Are we obliged to build with you?
What conditions come attached to the number, and what would move it?
Who owns the documents, and what happens if we take the work elsewhere?
You work in an agile way. How does a bounded discovery phase fit with that?
Can we settle the shape of the build instead?
Start the conversation that produces your number
Tell us what you are building, what it has to connect to, and what has already been decided internally. We come back with the shape of the phase and what it costs.
On request, a technical person joins within one business day to answer architecture and stack questions directly.
Two outcomes are good here: a scoped phase and a number we will sign against, or a clear answer that you do not need one.
- The documents are yours from Day 1.
- Nothing is open-ended.
- Nothing obliges you to build with us.