Most software projects do not fail in the code. They fail in the decisions made before the code — unclear requirements, skipped design, testing squeezed at the end. Custom software follows a predictable process, and understanding each stage is how a business stays in control of it.
The stages below, what each one produces, the decision you need to make in each, and the mistake that most often derails it — in that order.
The process at a glance
| Stage | Purpose | Typical deliverable |
|---|---|---|
| Discovery | Understand the business problem and who the software serves | Problem statement, stakeholder map, goals |
| Requirements | Define exactly what the system must do | User stories, functional requirements |
| Scope | Draw the boundary: what is in, what is out, what is later | Scoped specification, fixed estimate |
| UX/UI design | Design the screens and workflows people will use daily | Wireframes, clickable prototype |
| Architecture | Decide the technical foundation before building | Technical design document |
| Development | Build the software in reviewable increments | Working software, demoed regularly |
| Testing | Find defects systematically during the build | Test plans, defect reports |
| UAT | Confirm the software solves the business problem | Signed acceptance |
| Deployment | Move the system into real use safely | Live system, migrated data |
| Monitoring and maintenance | Keep it running, secure and improving | Monitoring, support arrangement |
Durations vary widely by project type — for how these stages translate into calendar time, see our custom software timeline guide.
1. Discovery
Purpose: establish what problem the software solves, for whom, and what success looks like — before anyone discusses features. Typical deliverable: a problem statement, stakeholder map and measurable goals. Key decision: whether the problem is worth solving with custom software at all, versus an off-the-shelf tool or a process change. Common mistake: bringing only managers to discovery sessions. The people who do the daily work know the exceptions and workarounds that the software must handle; without them, requirements are fiction. Our dedicated discovery guide walks through what good discovery looks like from the client's chair.
2. Requirements
Purpose: convert the understood problem into a precise description of what the system must do. Typical deliverable: user stories or functional requirements, plus the data the system must store — often a first data model and an integration map showing connections to existing systems. Key decision: which requirements are truly needed for the first release and which can wait; this is where disciplined prioritisation saves more money than any other activity. Common mistake: writing requirements as a wish list without trade-offs. Every requirement has a cost; a list with no priorities is not a specification, it is a dream.
3. Scope
Purpose: draw a firm boundary around the first release so estimates mean something. Typical deliverable: a scoped specification with explicit in/out/later lists and a fixed estimate tied to that scope. Key decision: signing off on scope only when you genuinely understand it — vague sign-off here becomes expensive argument later. Common mistake: treating the estimate as fixed while treating the scope as flexible. If new requirements enter mid-build without a change process, the timeline absorbs them silently until it breaks. Scoping a smaller first release? Our MVP scoping guide shows how to cut scope without cutting value.
4. UX/UI design
Purpose: design the actual screens, workflows and interactions before they are expensive to change. Typical deliverable: wireframes evolving into a clickable prototype you can tap through. Key decision: approving the prototype as your future daily tool, not as a picture — walk through real tasks in it. Common mistake: approving designs on looks alone. A beautiful screen that adds three clicks to the most common task will cost your team hours every week; changes at this stage cost hours, while the same changes during build cost days.
5. Architecture
Purpose: settle the technical decisions that are expensive to revisit: database choice, hosting and deployment pipeline, API structure, authentication, and how each external integration will work. Typical deliverable: a technical design document. Key decision: freezing the architecture in writing before build sprints start. Common mistake: letting stack decisions drift into the build. Mid-build technology changes are among the most expensive surprises in software, and a signed architecture document is what prevents them.
6. Development
Purpose: build the software in increments you can see and steer. Typical deliverable: working software demonstrated regularly — commonly every two weeks — starting with a working skeleton of the core workflow end to end, proving the architecture before the polish. Key decision: how to handle new requirements: they get scoped and priced as separate change orders instead of being quietly absorbed into a ballooning timeline. Common mistake: skipping reviews. Feedback in the third sprint is cheap; feedback after launch is expensive. Your participation here is not optional oversight — it is the cheapest quality control available.
7. Testing
Purpose: find defects systematically while there is still calendar time to fix them. Testing runs throughout the build, but it also needs dedicated time no sprint replaces: integration testing against real external services (which behave differently in production than in documentation), performance testing for bottlenecks that only appear under load, and security review for vulnerabilities functional testing never looks for. Typical deliverable: test plans and tracked, visibly shrinking defect lists. Key decision: what "done" means for each release — agreed quality criteria, not a feeling. Common mistake: testing "as we go" with no dedicated hardening time. A plan with no hardening phase is a plan with testing after launch.
8. UAT — user acceptance testing
Purpose: confirm with real users and real data that the software solves the business problem — the one checkpoint no vendor can do for you. Typical deliverable: formal sign-off against agreed acceptance criteria. Key decision: who tests and with what data: it must be your people, your scenarios, your data. Common mistake: treating UAT as a formality or delegating it to whoever is free. Perfunctory UAT is how businesses discover on launch day that the software does not match how they work. Our UAT guide covers how to run it properly.
9. Deployment
Purpose: move the system into real use without breaking the business that depends on it. Typical deliverable: the live system with migrated data, trained users and a rollback plan. Key decision: the cutover approach — big-bang switchover versus running old and new systems in parallel for a period. Common mistake: treating launch day as the finish line. Plan the cutover with the same seriousness as the build: data migration rehearsals, training scheduled before go-live, and support capacity reserved for the first weeks.
10. Monitoring and maintenance
Purpose: keep the system running, secure and improving after the project team leaves. Typical deliverable: monitoring and alerting in place, plus a support arrangement covering bug fixes, security updates and incremental improvement. Key decision: what level of ongoing support the system needs — and budgeting for it as an operating cost, not an afterthought. Common mistake: assuming software is "done" at launch. Expect a bedding-in period where real users find the edge cases no test plan imagined; budget the vendor's time for it. What belongs in a maintenance arrangement is covered in our support contracts guide.
Your role in each stage
| Stage | What the business must do |
|---|---|
| Discovery | Bring the right people, answer honestly, sign off only when you understand |
| Requirements and scope | Prioritise ruthlessly; treat scope changes as priced decisions |
| Design | Review the prototype as your future daily tool, not as a picture |
| Architecture | Ask what is hard to change later, and insist it is decided now |
| Development | Attend demos, give feedback within days, respect the change process |
| Testing and UAT | Provide real data and real testers; take acceptance seriously |
| Deployment | Plan cutover, training and support capacity before go-live |
| Maintenance | Report issues fast with reproduction steps; budget for upkeep |
The pattern: the vendor owns the how, you own the what — and the cheapest way to be a good client is speed. Every day a review or a UAT finding waits for your response is a day the team works around the gap or stands idle. Projects fail most often when the business goes quiet during the stages where its input matters most.
FAQ
Waterfall or agile — which process is better?
The distinction matters less than people think. What works for SME custom software is phased delivery with an agile build: fixed discovery and design upfront, then iterative sprints with demos, then dedicated hardening. Pure waterfall hides problems until the end; pure agile without upfront scoping drifts.
How involved do we need to be?
Three non-negotiables: engaged discovery (a few hours a week for two to three weeks), reviews every sprint (one hour, with decisions), and serious UAT (your people, your data, your sign-off). Everything else the vendor can carry — but not these three.
What if we need changes mid-build?
Expect them — then process them. New requirements get written up, priced and approved as change orders before work starts. What destroys budgets is not change itself but unmanaged change absorbed silently into the timeline.
How do we know the process is working?
You see working software every two weeks, the matches the agreed scope, defects are tracked and visibly shrinking, and nobody is surprised — by scope, by timeline or by cost. Surprises are the metric: a good process produces very few of them.
Starting a software project? Contact Tirupati Technologies to walk through what the process would look like for your requirements.