1. Define the goal and boundaries
The first stage asks which problem a change should solve and who experiences it today. A process map covers users, their goals, steps outside the screen, data sources and situations in which the normal path fails. It also distinguishes what observation supports from what remains an assumption. Without that distinction, a cost estimate can become a promise based on little evidence. Baseline measurement can be simple, but its method should be repeatable.
Discovery should end in a decision about the next step. That may be a prototype of the critical user journey, a test of an external interface or an assessment of data to be migrated. Recommending a purchased product or a process change is legitimate when custom software is unnecessary. Useful outputs are brief and concrete: a goal, roles, a data map, major risks, candidate approaches and criteria for choosing the first stage.
2. Design the architecture and its evidence
Architecture begins with boundaries of responsibility. Which system owns a value, who can change a state and how is an outcome passed to the next part of the process? The answers belong in interface contracts, a permission model and a few worked scenarios. Alongside the happy path, design for timeouts, duplicates, partial failure and reversal. Without these cases a diagram may look elegant while remaining impossible to operate clearly.
Evidence should match the largest risk. An unknown API calls for an integration experiment, a busy workflow for measurement on representative data and uncertain usability for a prototype with real users. Not every system needs microservices or a distributed platform. A well-structured modular application can simplify delivery and operation. More elaborate boundaries make sense only when concrete requirements outweigh the extra cost of communication, testing and monitoring.
3. Deliver in verifiable increments
Development is divided by outcomes that can be checked. The first complete path should connect interface, rules, data and observation in an operating environment, even if its scope is small. This exposes problems at the boundaries sooner than finishing screens or services in isolation. Later priorities change in response to findings, not only according to the original backlog order. The product owner needs to see what is done, what remains uncertain and how a decision changes scope.
For stable requirements, acceptance criteria can be specified in more detail. In an unknown environment, a range and an explicit plan for refining the estimate are more honest. Either way, the team maintains code, records of significant decisions, migration procedures and automated checks for critical rules as work progresses. Quality is not a final phase; it belongs in every increment. Technical debt should be recorded with its effect so it can be addressed deliberately.
4. Test the risks that matter
Tests should protect behavior whose failure would hurt users or operations. In a financial flow that might mean preventing a duplicate operation; in migrated data, preserving the meaning of a record; in internal AI, excluding sources the user cannot access. Automated checks are complemented by accessibility, understandable error messages and mobile behavior. Test data should represent exceptions rather than only the most convenient successful case.
Security review follows the actual assets and roles. Who may read personal data, who changes settings, where are secrets stored and what enters logs? Critical dependencies are kept current and changes reviewed. An external audit may be part of a project, but its scope and execution need evidence; general website copy cannot replace it. Equally, an automated accessibility score does not prove a user can complete the whole real task.
5. Release and hand over
Before a release, it must be clear how data changes, how the release is checked and who decides to roll it back. A data migration is often less reversible than code and deserves its own plan. A backup is valuable only if a usable service can be restored from it within an acceptable time. Monitoring should observe not only whether a server is up but also important workflows, failed requests, lagging integrations and exceptions awaiting human action.
Handover covers source access, deployment instructions, ownership of configuration, dependencies and incident procedures. A user needs to know how to get support and what happens to their information. A client needs to understand consequential architectural choices rather than depend on one individual. Documentation should be compact but usable when something goes wrong or another team takes over maintenance.
6. Measure and make the next change
After launch, actual outcomes are compared with the baseline. Faster processing helps only if errors or correction costs do not rise. A product may need other measures: task completion, data quality, manual interventions or availability of a critical path. Metrics need an owner and a question they help answer. A dashboard without a corresponding decision does not create value by itself.
Operating evidence may show that an original architectural choice no longer suffices, or confirm that greater complexity is unnecessary. The next stage should follow that evidence. Developing a system is not endless feature accumulation; it can also mean removing friction, simplifying a flow or retiring an unused component. When responsibilities and the reasons for decisions are traceable, a product can evolve without starting from scratch each time.