This isn’t a project management problem. It’s a foundation one.
The average software project runs 66% over budget and 33% over schedule. Teams spend almost half of their effort fixing problems that better foundation work would have prevented. When projects fail outright, 47% of the time it’s because requirements weren’t clear in the first place.
Foundation work is 10 to 20 percent of total project cost and removes 30 to 50 percent of the effort that would otherwise go into rework. That’s why we exist, and why this page leads with totals rather than fees.
The honest range.
Most app projects, foundation through to launch, land in one of three bands. The number depends on the complexity of what you’re building, the form factors involved, and the build route you take. Our foundation work is roughly 10 to 20 percent of the total. Paid earlier, in a form that makes the rest of the project cost less.
Early-stage products, simpler tools, projects with one core user journey on one form factor (typically a phone). Often a freelance or AI-assisted build after the foundation work.
Funded startups, products spanning phone and tablet or phone and web, established teams launching their next product. Build typically through a freelance team or a focused agency.
Healthcare, fintech, enterprise apps, compliance-heavy products. Multiple form factors, deeper research, fuller documentation, and a build that demands an experienced team.
All prices exclude VAT. Most projects run between ten and sixteen weeks for foundation, plus build time on top. Final price is shaped by the discovery call and the proposal that follows. Build costs based on industry rates and our experience across hundreds of projects.
What pushes a project’s price up or down.
The factors that move the number, in plain English. Highest-impact factors first. Each row shows roughly how much it shifts the total project cost.
Drives the total up
Higher day rates, project management, and overhead all add up.
More research, more documentation, more review at every stage.
Each device needs its own layout and design work.
APIs, payment providers, legacy systems. Each one adds complexity.
Two design systems, two specifications, more build work.
Diary studies, ethnography, and large-sample interviews take time.
Marketplaces, admin and end-user interfaces, B2B and B2C in one app.
Brand work has to happen before product design can lock in.
Drives the total down
Lower day rates, less overhead, often dramatically cheaper.
Cuts 30 to 50 percent of the effort that goes into building.
One layout, one set of components, one build path.
Less to design, less to specify, less to build.
Smaller first phase, then more once you’ve learnt what works.
Reuses the same design system across both platforms.
We build on your insights rather than starting from scratch.
Removes the brand-definition phase entirely.
Whichever route you pick, we make it cheaper and more likely to succeed.
Indicative costs for a typical mid-sized app. The solid section is initial cost. The patterned section is the probability-weighted cost of expected rework and rebuild risk.
How these numbers are calculated
Based on current UK market rates, McKinsey & Oxford data on software project overruns, and our own project experience. Expected rework is probability-weighted: the likelihood of significant rework multiplied by its typical cost. Our foundation work is consistent at £20K across routes, included in the With us initial cost. These are indicative, not quotes.Why this is the way we work.
Most agency pricing pages are a fiction. They tell you what their fee is and leave you to guess what the rest of the project will cost, knowing full well that the foundation work is only a slice of what you'll actually spend.
We do the opposite. We show you the total. Then we show you our part within it. We also show you what the work pays back, because foundation work doesn't add to your project cost. It reduces it.
In the video, I walk through why this matters, and what we mean when we say we recommend approaches rather than people.
No surprises in the proposal.
Most things are included in every engagement. A few things get handled separately, openly, when circumstances genuinely change.
Always included
Discovery and scoping
The conversations and structured workshops needed to define the shape of the project.
Revisions and reviews
Refinements within the agreed brief, with a defined review window per phase.
Stakeholder workshops
Working sessions with your team to align on direction, decisions, and emotional baselines.
The full design system
Components, states, tokens, documentation. Not a separate “design system phase”.
Complete technical specification
Architecture, data models, API documentation. Not an extra you buy alongside the design work.
Build recommendations
Independent advice on team shape, budget, and the smartest way to launch.
Walkthrough sessions
We walk you and any build partners through the handover in a working session.
Clarification calls during the build
We stay reachable if your developer has questions during construction.
Handled separately
Scope changes during the project
If your requirements genuinely change during the work, we agree the new scope and cost together before doing it. Never a surprise on the invoice.
When foundation work is worth it, and when it isn’t.
We’ll save you the discovery call: foundation work isn’t always worth it. Here’s the honest read on when it pays back, and when you’d be better off skipping it.
When it’s worth it
You’re building a consumer product
Retention, engagement, and emotional connection are what decide whether it succeeds. Foundation work is what makes those measurable and designable.
The product has to scale
Decisions made now will be expensive to undo later. Foundation work surfaces the ones that matter before they’re cast in code.
Your runway depends on it landing
If the cost of failure is significant, the cost of foundation work is dwarfed by what it prevents.
You’re in a regulated or sensitive sector
Healthcare, fintech, accessibility, safety. Getting it wrong has real cost. Foundation work is where you catch problems early.
You’re working with multiple stakeholders
Foundation work creates the shared brief that prevents months of internal disagreement during the build.
When it probably isn’t
You’re building an internal tool with five users
The investment doesn’t pay back. A good freelance designer can probably handle it directly.
You already have detailed research, strategy, and design
If the work has been done, redoing it is wasteful. We’ll review what you have and tell you what’s missing, if anything.
You’re building a quick prototype to test one assumption
Foundation work is for products you intend to scale. For one-week throwaway prototypes, skip it.
You’ve done this before with a similar product
If you’ve launched something close to this before and you have the patterns down, the foundation work is partly redundant.
From conversation to proposal to project.
Three steps from first contact to signed proposal. No pitch decks, no procurement theatre, no qualification calls before the qualification call.
Discovery call
Thirty minutes with Simon. We talk through your project, your team, your timeline. Honest read on whether we’re a fit and what shape the engagement might take.
A bespoke proposal
If a full engagement makes sense, we put together a proposal shaped around what we’ve learned. Not a tier you’ve been slotted into. A package designed for your project, your team, and your timeline.
The work, then the launch plan
Research, strategy, psychology-driven design, complete technical specification, and the smartest, most cost-effective way to launch. The whole thing, packaged and walked through. Yours to own.
