Custom software is built in seven stages: discovery, design, technical setup, build in short sprints, testing, launch and ongoing support. Each stage ends with something you can review, such as a written scope, clickable designs or a working demo, so problems surface while they are still cheap to fix. Your input matters most at discovery and testing.
This guide explains what happens at each step, how long it usually takes, what you should be doing, and the signs that a step has been rushed.
What are the stages at a glance?
Every stage has a clear output and a clear job for you; if either is missing, ask why. Here is the whole process on one page.
| Stage | What happens | Your role | What you receive |
|---|---|---|---|
| 1. Discovery | Map workflows, users, data and integrations | Explain how work is done today; share examples | Written scope, priorities, estimate |
| 2. UX and design | Wireframes, then clickable designs | Review screens with real tasks in mind | Approved designs for key flows |
| 3. Technical setup | Hosting, environments, repository, sign-in | Create or approve accounts in your name | Staging site, code repository you own |
| 4. Build sprints | Features built in one- or two-week cycles | Test each demo; answer questions quickly | Working software on staging, sprint by sprint |
| 5. Testing | QA, security checks, user acceptance testing | Run real scenarios with your staff | Bug-fixed release candidate |
| 6. Launch | Data migration, production release, training | Sign off; brief your team | Live system, admin guide |
| 7. Support | Fixes, monitoring, small improvements | Report issues; collect requests | Maintenance, phase-two plan |
Durations depend on scope. For a typical MVP, the whole sequence runs 8–16 weeks; our guide to realistic custom software timelines breaks that down by project type.
Step 1: What happens during discovery?
Discovery turns a rough idea into a written, prioritised scope that can be priced. It is the cheapest place to find mistakes.
Expect workshops or calls covering:
- Who uses the system and what each type of user needs to do.
- The current process, step by step, including the workarounds nobody mentions until asked.
- Data: what exists now, where it lives and how clean it is.
- Integrations: payment gateways, accounting tools, CRMs, messaging and anything else the software must talk to.
- Constraints: budget, deadline, compliance and hosting requirements.
Bring screenshots of current spreadsheets, sample documents and examples of software you like. The more concrete you are in discovery, the more accurate the price. The output should be a document you could hand to another developer and get a comparable quote.
Signs discovery was rushed: no written scope, no list of user roles, or a price given after a single short call for anything beyond a small tool.
Step 2: How does design work, and why come before coding?
Design comes first because changing a drawing takes minutes, while changing working code takes days. You approve how the software will look and flow before anyone builds it.
Design usually happens in two passes:
- Wireframes: simple layouts showing what goes on each screen and how screens connect.
- Clickable designs: realistic screens you can tap through, covering the most important flows.
Review designs by doing real tasks: "Create a new job and assign it to a technician", not "Does this look nice?" Involve one or two people who will use the software daily. They spot missing fields and awkward steps that owners overlook.
Step 3: What gets set up before building starts?
Technical setup creates the foundations: where the code lives, where the software runs and how changes reach users safely. You will not see much, but it decides how easy the system is to maintain.
Insist on:
- A code repository in your organisation's name (for example on GitHub or GitLab), with the development team given access.
- Hosting in your own cloud account, in a region that suits your customers and any data-residency needs.
- Separate staging and production environments, so every change is tested before customers see it.
- Automated deployments, so releasing a change is routine rather than risky.
This is also when the team picks the technology stack. Mainstream, well-supported choices make future hiring and handover far easier.
Step 4: What happens during the build sprints?
The software is built in short cycles, typically one or two weeks, each ending with a demo of working features. You should be clicking through real software within the first few weeks.
A typical sprint rhythm:
- Planning: agree which features are in this sprint.
- Building: developers write code, with tests where they pay off.
- Demo: the team shows what was built on the staging site.
- Feedback: you test it and raise changes or questions.
Your job here is speed. Answer questions within a day or two and test each demo while it is fresh. New ideas will come up; note them in a shared list and decide each one deliberately rather than slipping it into the current sprint. If you are unsure whether a change is worth it, our post on when custom software pays for itself offers a way to weigh value against cost.
Step 5: How is the software tested before launch?
Testing combines the team's own quality checks, a security review and your user acceptance testing. Each catches different problems.
- Developer testing: automated tests for business rules that must never break, like pricing calculations or permissions.
- QA testing: someone other than the developer works through every flow, on different devices and browsers, trying to break things.
- Security checks: reviewing authentication, permissions, input handling and configuration.
- User acceptance testing (UAT): your staff run real scenarios with realistic data and confirm the software does the job.
Security problems are often small configuration details. On GRWW's own systems, for example, we found a login rate limiter that trusted an IP header a client could spoof, which would have let an attacker keep guessing passwords; we fixed it. We also removed unsafe-eval from the site's Content Security Policy to limit what injected scripts could do. These are exactly the issues a dedicated review catches and a rushed launch misses.
Step 6: What happens on launch day?
Launch moves your real data into the new system, releases it to production and gets your team using it. A good launch is planned, rehearsed and a little boring.
A launch checklist usually includes:
- Final data migration, after a trial run on staging.
- Production deployment at a quiet time for your business.
- Monitoring and error alerts switched on.
- Backups confirmed and a restore tested.
- Staff training, plus a short written guide for admins.
- A rollback plan in case something critical goes wrong.
For bigger changes, consider a soft launch with one team or branch before rolling out to everyone.
Step 7: What does support look like after launch?
Expect a busy first few weeks of small fixes and adjustments, then a steady rhythm of maintenance and improvements. Software needs ongoing care, roughly 15–25% of the build cost per year as a typical range.
Agree in advance:
- Response times for urgent problems, such as the system being down.
- What maintenance covers: security updates, dependency upgrades, hosting management and bug fixes.
- How new features are requested, prioritised and priced.
Collect feedback from users during the first month. It is the best input you will ever have for phase two.
Which steps can you shorten safely?
You can shorten steps by preparing well, but you should not skip discovery, design review or testing. Those are the steps that prevent expensive rework.
Safe ways to save time: prepare data and integration access early, name one decision-maker, keep the first release lean and reuse standard services for payments, email and sign-in. If you are still deciding whether to build at all, start with our custom software vs SaaS scoring checklist, and for costs, contracts and ownership see the GRWW guide to custom software in 2026.
Frequently asked questions
How much of my time will the process take?
Plan for more time during discovery and user testing, and a few hours a week during the build to review demos and answer questions. One named decision-maker makes the biggest difference to speed.
Can I change my mind during the build?
Yes, but every change has a cost in time or money. Good teams log changes, estimate them and let you decide whether to add them now, swap them for something else or leave them for phase two.
What should I receive at the end of the project?
Working software in production, the source code in a repository you own, access to the hosting account, admin documentation and a record of what was built. You should be able to hand the system to another team if you ever needed to.
Is agile better than a fixed plan?
Most teams combine them: a fixed scope and price for the first release, built in short agile sprints with regular demos. That gives you budget certainty and early visibility.
Who tests the software, the developer or me?
Both. The development team should test thoroughly before you see anything, and your staff should then run real-world scenarios in user acceptance testing. Your testing confirms the software fits the business; theirs confirms it works correctly.
Start with step one
The easiest way to begin is a conversation about the process you want to replace and the people who use it. From there we can outline the stages for your project and send a fixed-price quote after a discovery call. You can see past builds on our work page.