Proving the Path Before Paving It: Using a Walking Skeleton to De-Risk a UK Software Build
Photo: Unknown authorUnknown author or not provided, Public domain, via Wikimedia Commons
Software projects rarely collapse in a single dramatic moment. They fail quietly in the first few weeks, when assumptions about architecture, third-party integrations and day-to-day user behaviour are cemented into a plan that nobody has yet tested. The cost of those assumptions only surfaces months later, by which time the budget is largely spent and the commercial leverage has shifted.
The walking skeleton is a well-established antidote to that pattern, and it deserves more attention from UK business leaders than it currently receives. The term comes from agile practice, but the idea is older than any methodology: build the thinnest possible version of the whole system, end to end, before building any part of it in depth.
What a walking skeleton actually is
A walking skeleton is not a prototype and it is not a proof of concept. A prototype is usually thrown away; a proof of concept usually tests one technical question in isolation. A skeleton is different in two respects. First, it is end to end: it touches every layer the finished product will touch, from the interface a user sees through to the database and back out to any external service. Second, it is intended to be kept. It is the spine that later feature work is hung on.
In practice, a skeleton for a customer portal might consist of a single login, one real record pulled from a live back-office system, one screen that displays it, and one action that writes a change back. That is all. It is narrow, but it is complete, and it will expose more risk in four weeks than a forty-page requirements document will in four months.
Why this matters more in the current climate
Boards and finance directors are scrutinising technology spend more closely than they have for a decade. Capital is expensive, headcount is constrained, and the tolerance for a twelve-month build followed by an uncertain launch has fallen sharply. Procurement teams are also under pressure to demonstrate that they have tested supplier assumptions rather than simply accepted them.
A skeleton gives a buyer something genuinely useful to put in front of a steering group: a working system, however limited, that has already connected to the systems that matter and been used by real people. It converts a promise into evidence at a fraction of the total cost.
The four assumptions a skeleton tests early
Architecture. Does the proposed approach actually hold together when identity, storage, messaging and deployment are wired up together? Many architectural decisions are cheap to change at week four and ruinously expensive at month nine.
Integrations. For most UK businesses the risk sits at the edges: an finance system such as Sage or Xero, a payment provider, a CRM, an HMRC service, a legacy database with no documentation. Integrations are where estimates go to die, because the true state of an external system is rarely known until someone attempts to talk to it.
User workflow. A skeleton puts a clickable, working thing in front of the people who will actually use it. Objections that would never surface in a workshop tend to appear within minutes.
Supplier assumptions. This is the commercial benefit that buyers underuse. A skeleton reveals how a supplier behaves when the work turns out to be harder than the pitch suggested: do they surface problems early or absorb them silently and ask for a change request later?
A phased budget model
The skeleton is not an additional cost so much as a reallocation of it. A workable structure looks like this:
| Phase | Purpose | Typical share of total budget |
|---|---|---|
| 0. Discovery | Confirm scope, constraints and the riskiest assumptions | 5 per cent |
| 1. Walking skeleton | One end-to-end slice, deployed to a real environment | 10 to 15 per cent |
| 2. Vertical slices | Complete two or three priority journeys in depth | 35 to 45 per cent |
| 3. Breadth and hardening | Remaining features, performance, accessibility, handover | Balance |
Two details matter more than the percentages. First, phase 1 should be priced firmly, with a defined exit point, so the buyer can stop there with a working artefact and a much better understanding of the terrain. Second, phase 2 should not be signed until phase 1 has been demonstrated. That single sequencing decision changes the balance of power in the relationship.
Writing it into the contract
A skeleton only de-risks a project if the commercial terms reflect its purpose. The supplier should be obliged to deploy to an environment the client controls, using the client's own source code repository and continuous integration pipeline from day one. That is not a hostile request; it is the standard means by which continuity is protected if the relationship ends.
The statement of work should also require a written record of decisions and trade-offs made during phase 1, and should confirm that the skeleton is production-quality code rather than scaffolding to be discarded later. If a supplier proposes building the skeleton in a different technology from the main build, treat that as a serious flag.
Red flags to watch for
- A skeleton that is delivered as screenshots or a clickable design file rather than a deployed system.
- Integration work deferred to a later phase because the third-party system is 'not ready'. In most cases the true answer is that nobody has tried.
- No use of real data, even anonymised or in a sandbox. Synthetic data hides exactly the messiness that causes rework.
- A revised estimate that grows substantially after phase 1 with no explanation of what was learned. Growth is normal; an unexplained growth is a symptom.
- Reluctance to let the client's own technical contact observe the work in progress.
Questions worth putting to any supplier
What is the narrowest end-to-end slice you would build first, and why that one? Which integration is most likely to fail, and what is your fallback? Who owns the repository and the deployment pipeline at the end of phase 1? Can we stop after the skeleton and still hold a working asset?
The answers will tell you a good deal about how the supplier thinks, well before you have committed the full budget. That, ultimately, is the point of the exercise.
A walking skeleton does not eliminate risk. It moves it to the start of the project, where it is cheap to address, instead of the end, where it is not. For UK organisations spending public or shareholder money on software, that is a trade worth making deliberately.
