Proving value early without throwaway work

Public bodies are right to be cautious about committing large sums before an approach is proven. Two tools help, and they are often confused: prototypes, which are built to learn, and a first working slice of the real system, which is built to prove. Each has its place.

Prototypes are for learning

The GOV.UK Service Manual advises teams in alpha to "build things that are just complex enough to let you test different ideas, not production quality code", and to "expect to throw away any code" at the end of the phase. That is sound advice. When the open question is which approach works for users, inexpensive prototypes answer it fastest.

A working slice is for proving

Once the approach is chosen, the remaining uncertainties are often technical. Can the data be extracted reliably from an existing system? Will the service perform with real volumes? Can the security requirements be met? These are best answered by building the thinnest end-to-end slice of the real service, to production standards, at the start of the build: one complete journey, with real integrations and real security controls, deployed through the real pipeline.

Choose the riskiest assumption

The Service Manual describes identifying the riskiest assumptions and testing them as a crucial part of alpha. The same principle should decide what the first slice of a build contains. Typical candidates include:

• an integration with an existing system that has never been connected before
• the quality of data in a source system
• a performance or volume requirement
• a security or accessibility requirement for a particular group of users

What the buyer gets

• working software on real or representative data, early in the engagement
• evidence rather than assurances about the hardest parts of the work
• an early and well-informed point at which to continue, adjust or stop
• nothing to rebuild if the work continues, because the slice is part of the final system

brytloop builds a proof of concept inside the build in this way, so that the first weeks of an engagement produce working software rather than a separate demonstration.