Most software projects do not fail because nobody had a good idea. They fail in the gap between a good idea and a working system, where ambiguity compounds: assumptions nobody wrote down, decisions made in passing, and a definition of done that drifts as the work goes on.
This is the process we use to take an idea to production. The stages are not novel, and we are not claiming otherwise. What makes them work is that each one produces a small written artefact, and that the artefact is cheap to be wrong about. The architecture reasoning underneath the middle stages is covered in designing scalable web applications.
- Discover: the problem, the users, the constraints and the risks.
- Architect: boundaries, data, integrations and the security model.
- Build: verifiable slices, with quality checked as they are built.
- Deploy: a rehearsed release, a rollback path and production verification.
- Scale: feedback, reliability and the next round of work.
Discover: reduce the idea to a problem that could be false
The most expensive input to a project is a solution looking for a problem. Discovery exists to convert an ambition into a stated problem, and a stated problem is the only kind that can turn out to be wrong.
The output is short: who has this problem, what they do about it today, what changes if it is solved, and what evidence would prove us wrong. If the team cannot answer those, the next stage has nothing to design against.
Two failure modes are worth naming because both look like progress. Confident enthusiasm, where a compelling demo gets mistaken for a validated need. And deferral, where a difficult question is left unanswered because it is awkward to raise. Both are far cheaper to catch here than anywhere later.
Discover: write down the constraints before the architecture
Constraints are usually discovered later and treated as surprises. A deadline, a hosting platform that cannot be changed, a data residency requirement, a team that has never run this technology, an integration with a system nobody controls: each of these removes options, and each is cheaper to know before the design than after.
The same discipline applies to non-goals. Writing down what the first version will not do is the most effective scope control there is, because everything you defer stays coherent later while everything you half-build has to be maintained forever. A non-goal list is short, and it is the section of the document most often deleted by someone who did not write it.
Discover: prototypes, only where the answer would change the design
A prototype is worth building when a specific unknown is expensive to resolve later and cheap to resolve now: whether a vendor can meet a latency requirement, whether a browser supports an approach you depend on, whether an interaction is usable at all.
It is not worth building to make a stakeholder excited, to settle a question that reading the documentation would answer, or to produce something that will be thrown away without anyone learning from it. Time-box it, write down the question it is answering before starting, and decide in advance what evidence would count as an answer.
Architect: decide the consequential things while they are still cheap
Architecture is the set of decisions that are expensive to reverse, made while the answers are still cheap. That means naming the boundaries, choosing the data model, defining how the system fails, and agreeing what is out of scope. Scope decisions belong here because they are architectural in effect.
Write the decisions down with the reasoning and the rejected alternatives. Six months later the reasoning is the valuable part, because nobody remembers why the obvious option was not chosen. A short record of three decisions and their trade-offs is worth more than a diagram nobody can interpret.
Architect: keep a risk register, because surprises are structural
Risks on a project are not a list of things that might go wrong in the abstract. They are specific, owned and reviewed, and a useful entry names the trigger rather than the worry.
- A named technical risk, with the assumption that would have to hold for it to bite, and the cheapest test that assumption.
- A delivery risk, where the uncertainty is about the team rather than the technology: an unfamiliar stack, a single person holding key knowledge, a dependency on a third party's timeline.
- An integration risk, where something outside the team's control is on the critical path and no fallback has been agreed.
- An operational risk that only appears after launch, such as a migration that has never been rolled back.
The entry that earns its place is the one with a test attached. A risk with a cheap way to test it stops being a risk, and a risk that cannot be tested at all is a decision that has not been made yet.
Build: build in slices that can be verified
The unit of delivery should be something that can be seen to work, not a layer of the stack. A vertical slice through the architecture proves the decisions were right; a completed data layer proves nothing on its own and cannot be verified until something sits on top of it.
Make the definition of done explicit
A feature is done when it works, has been reviewed, has tests at the level its risk warrants, is accessible, is instrumented, and is documented enough for the next person. Writing that list down before starting prevents the slow drift where each omission looks reasonable on its own.
Keep the build green and fast
Continuous integration with a quick, reliable suite is what makes it safe to change anything. The suite should cover the risk rather than the implementation: what the system does, and the boundaries where it meets something it does not control. A slow suite gets bypassed, and a bypassed suite is worse than a small one because it still looks like coverage.
Treat review as design feedback
Review exists to catch misunderstanding, not typos. If review only ever finds style issues, either the team is not reviewing design or the design was never contested. Both are worth knowing.
Build: cross-cutting work is a gate, not a phase
Security, accessibility and performance are usually scheduled as tasks, which means they happen last and run out of time. Treating each as a condition every slice must satisfy changes the economics: the work is small while the code is still small.
- Security: threat model the new surface, check authorisation on every path that touches data, keep secrets out of the repository, and run dependency and static analysis in the build.
- Accessibility: semantic elements first, keyboard paths for anything interactive, labels on every control, and contrast checked in review rather than at the end.
- Performance: budgets and assertions on the paths that matter, added when the path is built, with the same profile used for the check as for the measurement.
Each of these has the same failure mode. Deferred to the end, all three become expensive discoveries on a date that cannot move, and the response is usually a documented exception. The reason to treat them as gates rather than tasks is that the exception is a decision, and decisions should be made deliberately rather than by running out of quarter.
Deploy: make releases uneventful and rehearsed
The aim is a release process with no novel steps, exercised in advance rather than during an incident.
- Migrations that are additive and backwards-compatible, following an expand, migrate, contract sequence so the previous release keeps working while the new one rolls out.
- Feature flags, so behaviour can change without a deployment and a risky change can be enabled gradually.
- Automated checks on every change: type checking, linting and the test suite, all blocking.
- Staged exposure, from an internal environment to a small slice of real traffic, before the full release.
- A rollback path that has been performed at least once, including the data migration, which is the step teams most often discover has no answer.
The four gates between the five stages
Gates exist to make a decision explicit at a point where it is still cheap. Five stages have four boundaries, and four are usually enough, each with an entry condition and something demonstrable to leave with.
- Problem agreed: a written problem, the current alternative, and what would prove the team wrong. Nothing is estimated before this exists.
- Design agreed: boundaries, data model, failure behaviour, non-goals, and a risk register with a test attached to each live risk.
- Slice ready to ship: the slice works end to end, the definition of done is satisfied, and the three cross-cutting gates have been checked on the paths the slice touches.
- Release approved: staged exposure complete, rollback rehearsed, dashboards and alert thresholds in place, and the release note written for whoever is on call.
The gate is the artefact, not the meeting. If a stage produced only a conversation, the reasoning is lost and the next person repeats the same discovery.
Deploy: production verification is its own step
Deploying is not the same as having deployed. The interval between a release and the first evidence that it works is where most of the avoidable damage happens, and closing that interval is a deliberate step rather than something that happens on its own.
What it involves in practice: watch error rate and latency for the paths the release touched, confirm the queues are draining rather than filling, check that background jobs are actually running rather than merely enabled, and exercise the two or three user journeys the change was meant to affect. Then write down what was observed. That record is what makes the next release a comparison rather than another unknown.
Instrumentation has to exist before this step, not during it. Structured logs carrying a request identifier, error tracking that groups by cause, and metrics on the things users feel. Adding them during an incident is too late, because the information needed to reconstruct it was never recorded.
Scale: feed reality back into the backlog
Launch is a transition rather than a finish line. A roadmap written before launch tends to persist long after it stops reflecting what users need, and a short regular review of what shipped, what was used and what broke is worth more than a comprehensive plan nobody revisits.
Two habits make the difference. Small, frequent releases localise mistakes, because the change is recent and the diff is small; releasing rarely accumulates risk between deployments. And maintenance is scheduled work rather than emergency work: dependencies need updating, certificates expire, and the platform underneath will change whether or not anyone is looking.
Scale: scaling the process down without losing the record
The stages above assume a team that can afford them, which is not always the case. The useful move is to keep the artefacts and shrink the time spent producing them.
On a small, well-understood change, discovery can be a paragraph and architecture can be a note saying the existing pattern applies. What should not shrink is the written record of the decision, because that artefact is the one whose value grows with time. For larger work the same stages apply with the opposite emphasis: more time on discovery and architecture, less on producing documents nobody will read.
The common mistake is applying one heavyweight process to everything, which teaches the team to route around it. A process that has to be justified for each change is one that will eventually be skipped.
Scale: signs the process is working
These are qualitative rather than numerical, and they are more informative than any single metric.
- A new engineer can find the reasoning behind a decision without scheduling a meeting.
- Releases are unremarkable. Nobody is holding their breath before a deployment.
- When something breaks, the logs answer the question without archaeology.
- The roadmap reflects what users actually need rather than what was planned a year earlier.
- Bugs are found before users report them, at least on the paths that matter.
Why the stages are written down at all
Taking an idea to production reliably is mostly about closing the gap between ambition and system. The five stages are Discover, Architect, Build, Deploy and Scale, each asking for something specific. Reduce the idea to a problem that could be false, write down the constraints and the non-goals, decide the expensive things while they are cheap, keep risks and their tests visible, build in verifiable slices against an explicit definition of done, treat security, accessibility and performance as gates, rehearse the release, and keep the loop closed after launch.
None of it is novel, and that is deliberate. A process that depends on talent in the moment is not a process, and the value of writing each stage down is that the team keeps the benefit after anyone's attention moves on.
Our approach describes how we run it, and what we do at each stage covers the work itself. If you are weighing a build that has to last longer than its first release, one of the industries we work in is often a useful place to start the conversation.
