What this analysis is — and is not
The Kinetic Axis project estimator uses a simple, published scoring model. A project area sets a base complexity score. Each selected capability adds points. A legacy starting point adds two, a premium delivery expectation adds two, and a prototype expectation subtracts three. The total maps to one of five planning bands.
The scenario counts below use the estimator’s “Our rate” bands. The standard-industry reference shown alongside them is a comparison point and is not included in the counts.
To test the model rather than a handful of examples, we enumerated every combination: 10 project areas × 256 capability sets × 3 starting points × 3 delivery expectations. That produces 23,040 distinct scenarios. Every scenario is reproducible in the estimator by selecting the same inputs.
This is not a survey of client invoices, a regional rate card or a claim about what the market charges. It is an analysis of how one transparent planning model behaves when scope changes. The value is in the relative movement between scenarios, not in treating any single band as a quote.
- No client data, confidential briefs or individual estimates were used
- The model excludes VAT, third-party licences, hosting, support and internal client time
- The bands are deliberately broad planning ranges, not priced proposals
- The analysis is deterministic: the same inputs always produce the same band
Where the scenarios land
The distribution is concentrated in the middle. The £35k–£60k band is the largest single group at 43.8%, followed by £20k–£35k at 38.2%. Together, those two bands account for 82.0% of all scenarios.
The lower bands are much thinner than buyers often expect. Only 1.3% of combinations land at £5k–£10k and 9.8% at £10k–£20k. That does not mean small projects are impossible; it means the model reaches those bands only when the project area, capability set and delivery expectation are all restrained.
At the other end, 6.9% reach £60k+. Those scenarios tend to combine a complex project area, most capabilities and either a legacy starting point or a premium delivery expectation.
| Indicative band | Scenarios | Share |
|---|---|---|
| £5k–£10k | 294 | 1.3% |
| £10k–£20k | 2,256 | 9.8% |
| £20k–£35k | 8,797 | 38.2% |
| £35k–£60k | 10,095 | 43.8% |
| £60k+ | 1,598 | 6.9% |
Project area changes the starting point
The project area sets the first assumption. A website or a design-system engagement starts with fewer complexity points than a bespoke internal system or a mobile product. That is why the median website scenario sits a band below the median bespoke-software scenario.
The more useful number is the share of scenarios at £35k or above. A website still reaches that band in 19.9% of combinations, usually when several capabilities and a premium expectation are added. Bespoke software, mobile and SaaS reach it in 68.5% of combinations — not because every project costs that much, but because their starting point is higher and the model has less room to stay low.
Treat the median as a starting assumption, not a verdict. A tightly scoped web application can sit in a lower band; a website with extensive integrations and migration can sit in a higher one.
| Project area | Median band | Share at £35k+ |
|---|---|---|
| Website / web design | £20k–£35k | 19.9% |
| Web application / portal / dashboard | £35k–£60k | 58.9% |
| Bespoke software / internal systems | £35k–£60k | 68.5% |
| Mobile application | £35k–£60k | 68.5% |
| Digital product / SaaS | £35k–£60k | 68.5% |
| Ecommerce / marketplace / loyalty | £35k–£60k | 58.9% |
| API / systems integration / payments | £20k–£35k | 37.8% |
| UI/UX / design systems / branding | £20k–£35k | 29.0% |
| Improve or modernise an existing product | £20k–£35k | 48.8% |
| Something else | £20k–£35k | 48.8% |
Capabilities stack faster than the first three suggest
The clearest pattern in the analysis is the capability count. With zero to three selected capabilities, the median scenario stays at £20k–£35k. At four capabilities it moves to £35k–£60k, and at seven or eight the median reaches £60k+.
This is not because each capability is individually expensive. It is because the bands are five points wide and most capabilities add two points. The fourth selection is often the one that crosses a boundary. In the model, the share of scenarios at £35k+ jumps from 27.3% with three capabilities to 51.6% with four.
That has a practical implication for scoping. A first release with accounts, an admin workspace, reporting and one integration is already a four-capability product. If the budget assumption was built around two capabilities, the gap is not a negotiation tactic; it is a different amount of work.
| Capabilities selected | Median band | Share at £35k+ |
|---|---|---|
| 0 | £20k–£35k | 0.0% |
| 1 | £20k–£35k | 0.4% |
| 2 | £20k–£35k | 7.7% |
| 3 | £20k–£35k | 27.3% |
| 4 | £35k–£60k | 51.6% |
| 5 | £35k–£60k | 74.9% |
| 6 | £35k–£60k | 91.3% |
| 7 | £60k+ | 97.8% |
| 8 | £60k+ | 100.0% |
The same scope can move a band on delivery expectation alone
Delivery expectation is not a cosmetic choice. In the model, a prototype expectation subtracts three points and a premium expectation adds two. That five-point spread is the width of a whole band, so the same project area and capability set can land in different bands without any change in feature list.
The result is visible in the distribution. Prototype scenarios have a median of £20k–£35k and only 22.4% reach £35k+. Production-ready scenarios have a median of £35k–£60k and 54.5% reach £35k+. Premium scenarios reach £35k+ in 74.8% of cases and £60k+ in 15.2%.
Starting point has a similar effect. An existing product or legacy system adds two points, taking the median from £20k–£35k to £35k–£60k and the share at £35k+ from 44.4% to 63.6%. That reflects the work of understanding, protecting and migrating something that already exists — not simply rewriting the same screens.
| Delivery expectation | Median band | Share at £35k+ |
|---|---|---|
| Prototype / proof of concept | £20k–£35k | 22.4% |
| Production-ready | £35k–£60k | 54.5% |
| Premium / highly polished | £35k–£60k | 74.8% |
What the model cannot tell you
A scenario analysis is only as good as its assumptions. This model does not know the client, the team, the risk, the quality of the existing data or how quickly decisions will be made. It does not include VAT, cloud hosting, third-party licences, ongoing support or the client-side time needed to define and test the product.
It also does not adjust for region, sector or the day rate of a particular supplier. Two studios can quote differently for the same scope because of seniority mix, delivery model, margin and risk. The bands are a way to compare the shape of a project, not a way to declare one quote correct.
The honest use of the analysis is to ask better questions: how many capabilities are genuinely in the first release, what already exists, how polished does it need to be, and what would have to be true for the project to fit a lower band? Those questions are more useful than arguing over a single number.
- It is not a survey of what UK businesses actually paid
- It is not a substitute for discovery, technical review or a scoped proposal
- It does not include VAT, hosting, licences, support or internal client costs
- It does not account for sector-specific regulation or integration complexity outside the selected capabilities
How to use the bands in a budget conversation
Start with the project area, then list the capabilities that must be in the first release rather than the full eventual product. Count them honestly. If the list reaches four or more, expect the conversation to move into the £35k–£60k band unless the scope is deliberately reduced.
Then separate the starting point from the ambition. A legacy system adds work before the new product exists. A premium expectation adds design, testing and polish across the whole product. Both are legitimate choices; neither is free.
Finally, use the estimator to test two or three versions of the scope rather than one. A first release that proves the core workflow may be a better investment than a broader product that takes longer to reach users. The bands are most useful when they help make that trade-off explicit.
- List must-have capabilities separately from later-phase ideas
- Decide whether the first release is a prototype, a production tool or a premium product
- Account for migration and integration as real work, not background tasks
- Ask which single capability could move out of the first release without weakening the test
- Treat the output as a planning range and validate it with a scoped conversation