Walking Skeleton
also called Tracer Bullet Slice, Thin End-to-End Slice
The thinnest real slice of a system, deployed through the real pipeline from the first week, so integration and deployment risks surface when fixing them is cheap.
A team spends five weeks building screens and business rules on laptops. In week six they try to deploy and find that authentication does not work behind the company proxy, the database migration tool conflicts with the hosting platform, and nobody has set up monitoring. A walking skeleton is the answer: one tiny feature that runs end to end through every real layer and into a real environment in the first week or two.
Why it matters
The riskiest parts of a new system are usually the joins between things, not the features: build, deploy, identity, data migration, observability. Their cost of change is lowest at the start and rises with every feature built on top of them. Alistair Cockburn named the idea in the Crystal methodology: the skeleton does little but links the main architectural components. It is how evolutionary architecture gets its first feedback.
Implementation patterns
- Pick one feature that touches every layer: for example, "a signed-in user saves a note and sees it listed".
- Use the real pipeline: build, automated test, deploy to an environment that matches production in its structure, even if it is small.
- Include the unglamorous parts: login, a migration, a log line, a health check and one alert.
- Time-box it: days, not weeks. If it takes a month the slice is too large.
- Mark choices provisional: note which decisions the skeleton made by default (database, framework) and which are meant to last.
- Keep it deployable: every later change goes through the same pipeline, so it never rots.
Industry example
The idea originates with Cockburn's Crystal work, and closely related is the "tracer bullet" in The Pragmatic Programmer (Hunt and Thomas, 1999). No single company is claimed here. As an archetype, a payments start-up of six engineers built a skeleton that created a test payment, wrote it to the database and showed it on a page, deployed to a staging account in the first nine days. It exposed an identity-provider callback restriction that would have cost a sprint to discover later.
Failure scenarios
- Skeleton never deployed: it runs only locally, which defeats the purpose.
- Skeleton becomes the product by default: early provisional choices (a database picked in an afternoon) are never revisited.
- Too large: a "skeleton" of ten features is simply the first release.
- Skipping observability: the first outage arrives with no logs to read.
- Different environment: staging has no proxy, so the proxy problem returns at launch.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Walking skeleton first | Integration risk found in week one | Days of work before any visible feature |
| Features first | Early demos | Late discovery of deployment and identity problems |
| Prototype outside the pipeline | Fast exploration | Rework to productionise |
When not to use it
A throwaway prototype that will never reach users does not need a pipeline. A small script or a single-page tool with no integrations has no joins to test. Use the skeleton when the system has several layers, several teams or a hosting environment you have not used before.
Interview question
Q: You have two engineers, six months and no users. What do you build in the first two weeks, and why?
What a strong answer covers: a thin deployed slice through every layer with real login, a migration and monitoring; reasons (joins are cheapest to fix now); what is deliberately left out; which choices are provisional and when you would revisit them; and what you would cut if the time-box slips.
Quick check
Quiz: What does a walking skeleton validate that a polished feature does not? The build, deployment, identity and data joins between layers.
Flashcard: How long should a walking skeleton take? — Days, not weeks; a month means the slice is too large.