A custom software development process that moves from problem discovery and prototypes to an MVP and production through evidence-based decision gates.
- Discovery reduces uncertainty about users, workflow, data and risk; it is not a hidden start to building the entire product.
- An MVP is the smallest end-to-end slice that creates value and evidence, not a full product with testing, security or operations removed.
- Every stage needs a decision gate: continue, change the hypothesis, split scope, buy rather than build, or stop deliberately.
Stage 0: confirm that the problem is worth solving
Before discovery, write a short problem brief: who experiences the problem, what happens today, how the consequence is measured and who owns the outcome. Do not begin with screens or technology. If an available product meets most needs and the workflow is not differentiating, buying or configuring may be better than building.
The first gate asks whether deeper investigation is worth funding. Initial evidence can include handling time, error count, handoffs, task cost or user feedback. Without a baseline, the project will struggle to show that software created a real change.
- One priority user group and workflow.
- The current baseline and intended outcome.
- Owners for the decision, data and budget.
- A buy, build or hybrid hypothesis to test.
A good process does not make every hypothesis correct. It exposes the wrong ones while the cost of changing direction is still low.
Stage 1: discovery to reduce uncertainty
Discovery gathers evidence about users, workflows, data, policy, related systems and technical constraints. Activities can include interviews, observation, workflow mapping, data audit and API tests. The GOV.UK Service Manual says not to start building the service in discovery; the purpose is to understand the problem and decide whether exploring solutions is worthwhile.
Outputs should be concise and usable: a problem statement, user groups, process map, value hypothesis, risks, exclusions and validation plan. Friday Works commonly plans focused discovery over 1–3 weeks when the problem and participants are ready; actual duration depends on data fragmentation and stakeholder count.
- Evidence from real work, not only opinions in a meeting.
- The largest value, usability, data, integration and security risks.
- Assumptions that must be tested before a deeper estimate.
- Decision gate: stop, buy, prototype or continue with a narrow scope.
Stage 2: prototype and alpha to test solution directions
A prototype can be an interface flow, data model, API spike or service simulation. Select it for the uncertainty it must reduce: test an interface when user comprehension is unclear; call the real API with synthetic data when integration is risky; model roles first when access boundaries are uncertain.
In GOV.UK terminology, alpha is where teams try different solutions to the problems learned in discovery. Experimental code does not all need to survive. The valuable output is evidence: whether the approach is usable, whether integration works, which architecture assumptions failed and what belongs in a beta or MVP.
- A prototype matched to the risk instead of a polished demo of everything.
- Structured test data and evaluation criteria defined in advance.
- A decision log for architecture choices and rejected options.
- Decision gate: is one direction viable enough for an end-to-end build?
Stage 3: an MVP is an operational slice, not careless software
An MVP should complete one important journey end to end for a narrow user group. It includes sign-in, permissions, data, error handling, measurement and proportionate support. Reduce scope by reducing roles, workflows or integrations, not by removing acceptance criteria, testing or data protection.
NIST SSDF treats security requirements, component protection, well-secured production and vulnerability response as lifecycle practices. Security is therefore not a package added after the MVP. A first release can be narrow while authentication, authorisation, secrets, logging and dependency updates still match the data and impact involved.
- One outcome and one priority user group.
- A usable, measurable end-to-end journey.
- Acceptance criteria, observability and a safe fallback.
- A decision gate based on use, quality, cost and risk.
Stage 4: production, operations and the improvement loop
Before production, complete migration, environment configuration, backup and recovery, monitoring, runbooks, access, documentation and support planning. A beta or limited release tests the system with real users and controlled traffic before expansion. GOV.UK describes live as an ongoing phase rather than an endpoint; the service continues to evolve around established user needs and operational evidence.
After launch, prioritise the roadmap using evidence: which capabilities are used, where errors happen, which workflows still leave the system and what each unit of outcome costs. A regular review also checks dependencies, access, infrastructure cost and architecture assumptions that have changed.
- A release checklist, migration plan and rollback.
- Dashboards for errors, performance, usage and cost.
- Runbooks, support ownership and a vulnerability-response process.
- A roadmap based on data rather than the old wish list.
FAQ
Frequently asked questions
What are the stages of a custom software development process?
A practical process confirms the problem, runs discovery, tests prototypes or alpha solutions, builds an end-to-end MVP, uses a controlled beta, moves to production and continues an operations–improvement loop.
What is an MVP?
An MVP is the smallest release that creates value for a user group and produces evidence about an important hypothesis. It is not a full product with testing, security or operating support removed.
Does discovery include coding?
Discovery should not quietly begin building the product. A very small prototype or technical spike can test risk, but the main output is understanding the problem, assumptions, scope and next decision.
When should a software project stop?
Stop or change direction when evidence shows the problem lacks value, users reject the approach, data or integration is not viable, or cost and risk exceed the agreed threshold.
How long does Friday Works take to build an MVP?
A focused MVP is commonly planned into an 8–14 week range after discovery. Actual duration depends on workflow, data, integrations, security and the required operating readiness.
References
Sources used in this guide
We prioritise official guidance and primary technical sources. Visit each source for full context and the latest updates.