Most business owners who commission custom software have never done it before. They know their business deeply but have little idea what happens between the first meeting with a developer and the day their team starts using the new system. That gap creates anxiety, unrealistic expectations and — too often — projects that disappoint both sides. This guide explains the custom software development process from the client's point of view: what happens in each stage, what you should receive, what decisions you will be asked to make, and the warning signs that something is going wrong.
The process described here reflects how experienced development teams build business software — web applications, mobile apps, internal systems and portals. Names of stages vary between companies, but the substance is the same.
The shape of a healthy project
A healthy project moves from uncertainty to certainty in steps. At the start, almost everything is uncertain: scope, effort, risks, even whether the idea is the right solution. Each stage should reduce uncertainty before committing larger amounts of time and money. Projects fail most often when they commit heavily while uncertainty is still high — for example, signing a large fixed contract on the basis of a two-page brief, or writing code before anyone has agreed how an order should flow through the business.
The stages are:
- Initial conversations and fit
- Discovery
- Design (experience and technical)
- Development in iterations
- Testing and acceptance
- Data preparation and launch
- Stabilisation, support and evolution
Stages overlap. Design continues while early features are built; data preparation starts long before launch. But each has a distinct purpose.
Stage 1: Initial conversations
Purpose: decide whether it makes sense to work together and whether custom software is the right answer at all.
In the first conversations, a good development partner asks more about your business than about features: what problem you are solving, what it costs you today, who is affected, what you have already tried and what success would look like a year after launch. They should also be willing to say when custom software is not the right answer — when a well-configured off-the-shelf product, or a simpler process change, would serve you better.
What you should receive: a summary of their understanding of your problem, a rough range for effort and timeline with the assumptions behind it, and a proposal for discovery.
Warning signs: a detailed fixed quote after one meeting; no questions about your business; promises that everything you mentioned is easy.
Stage 2: Discovery
Purpose: turn an idea into a plan that both sides understand and can commit to.
Discovery is the most underrated stage. It is where the development team learns how your business really works — not how the process document says it works. Typical activities include:
- Interviews and observation. Talking to the people who will use the system: coordinators, technicians, store keepers, salespeople, accountants, managers. Watching them work for an hour often reveals more than a day of meetings.
- Collecting artefacts. Forms, spreadsheets, reports, WhatsApp groups, printed job cards, invoices. These show the real data and the real exceptions.
- Mapping workflows. Drawing the main processes step by step, including who does what, what information is needed and what happens when things go wrong.
- Identifying data and integrations. Which existing systems hold data, which must exchange data with the new system, and what access is available.
- Agreeing priorities. Separating what is essential for the first release from what can follow.
- Identifying risks. Unclear rules, poor data, dependency on third parties, unusual hardware, regulatory needs.
Discovery for a focused business application might take one to three weeks; for a complex multi-department system, longer.
What you should receive:
- A scope document for the first release, written in business language.
- Workflow diagrams for the main processes.
- A list of user roles and what each can do.
- A prioritised feature list (often called a backlog).
- Screen outlines or wireframes for key screens.
- A technical approach: platforms, architecture, hosting, integrations.
- A plan and estimate for the first release, with assumptions and risks stated.
Decisions you will make: what is in and out of the first release; who owns decisions on your side; how success will be measured.
Warning signs: discovery that only talks to the business owner, never to users; a scope document full of technical jargon you cannot check; no list of assumptions; risks described as "none".
A note on "the product owner"
Every successful project has one person on the client side who can make decisions about the software — what it should do, in what order, and whether a feature is acceptable. This person needs to know the business, be available every week, and have the authority to decide. When decisions require a committee, every question waits days and the project slows to a crawl. Choosing your product owner is one of the most important decisions you will make.
Stage 3: Design
Purpose: decide how the software will work for its users and how it will be built.
Experience design
Experience design shapes what users see and do: the flow of screens, the information on each, the number of taps or clicks to complete a task. For business software, good design is not about decoration; it is about speed and clarity. A technician closing a job in a basement with dirty hands needs large buttons and few steps. A coordinator handling fifty calls a day needs keyboard shortcuts and a dense, readable list. A director needs to see in ten seconds what needs attention.
Clickable prototypes — screens linked together so users can tap through a flow — are the most effective tool here. Putting a prototype in front of real users and watching them try to complete a task reveals problems that no amount of discussion would.
Technical design
In parallel, the technical team designs the data structure, the architecture, security, hosting, integrations and the approach to things like offline use, notifications and reporting. You do not need to understand every technical detail, but you should understand the important choices and their consequences: where the system will be hosted and who controls it, how data is backed up, how the system will scale, and which parts depend on third-party services with their own costs and limits.
What you should receive: prototypes or designs for the main flows, approved by real users; a short technical overview in plain language; a decision record for major technical choices.
Warning signs: designs approved only by managers who will not use the system; no prototype testing; technical choices that tie you to a single vendor without explanation.
Stage 4: Development in iterations
Purpose: build the software in small, demonstrable pieces, adjusting as you learn.
Modern development teams work in short cycles — usually one or two weeks, often called sprints. At the start of each cycle, the team and the product owner agree which items from the backlog will be built. At the end, the team demonstrates working features — not slides, not screenshots, but software you can try.
This rhythm has big advantages for you as the client:
- You see progress regularly and can judge it yourself.
- Misunderstandings are caught within weeks, not months.
- You can change priorities as you learn, without throwing away work.
- Risks surface early, while there is still time to respond.
Your role during development: attend demos, try the features in a test environment, answer questions quickly (ideally within a day), make prioritisation decisions and provide test data and documents when asked. Slow client responses are one of the most common causes of delay.
What you should receive: regular demos; access to a test environment; a visible backlog showing done, in progress and remaining items; honest updates on risks and changes to the plan.
Warning signs: weeks without anything to see; progress reported only as percentages; demos that show the same features again; reluctance to give you access to the test environment or the code repository; risks that appear only near the deadline.
How changes are handled
You will learn things during development that change your mind. That is normal and healthy. A good process handles change explicitly: the new request is described, estimated and compared with the remaining work. Then you decide — replace something planned, extend the timeline or budget, or postpone the request to a later release. What should never happen is silent scope growth, where everything is added and the trade-off appears only when the deadline is missed.
Stage 5: Testing and acceptance
Purpose: confirm the software works correctly and is ready for real users.
Testing happens at several levels. Developers write automated tests for important logic. The team's testers check features as they are built. Before launch, there is a focused period of user acceptance testing (UAT), where your own people use the system with realistic data and scenarios.
Prepare for UAT by writing down the scenarios that matter: a normal order, an urgent order, a cancelled order, a partial delivery, a return, a customer with special pricing, a technician who loses network halfway through a job. The best scenarios come from the awkward cases your staff deal with every week.
What you should receive: a test environment with realistic data, a way to report issues and track their status, and a clear list of known issues with their severity before launch.
Decisions you will make: whether the software is acceptable for launch, and which known minor issues can be fixed after launch.
Warning signs: UAT squeezed into a few days before launch; testing only "happy paths"; pressure to sign acceptance before your users have tried the system.
Stage 6: Data preparation and launch
Purpose: put the software into real use safely.
Launch involves more than switching on a server. Customers, products, assets, price lists and open transactions need to be cleaned and loaded. Users need accounts and training. Old processes need to be switched off at the right moment. Many businesses launch in stages — one branch, one team or one product line first — to reduce risk.
A launch plan should state the date and time of cut-over, the final data migration steps, who validates the data, how users will be supported in the first days, and what will happen if a serious problem appears (including whether and how to roll back).
What you should receive: a launch plan, training sessions or materials by role, migrated and validated data, and a support arrangement for the launch period.
Warning signs: data migration discussed for the first time in the final weeks; no rollback plan; no one from the development team available during the first days of use.
Stage 7: Stabilisation, support and evolution
Purpose: keep the software healthy and make it better.
The first few weeks after launch bring a burst of small issues and requests as real users meet real situations. A stabilisation period with quick responses builds confidence. After that, software enters its long life: bug fixes, security updates, adjustments for new phone and browser versions, performance tuning and new features based on how the business uses the system and how it changes.
Agree a support arrangement in advance: response times by severity, how requests are submitted and prioritised, how small improvements are handled, and how larger new features are planned. Treat the software as a living asset with a budget, not a one-off purchase.
What you should receive at handover: the source code in a repository you control; documentation for users, administrators and developers; deployment instructions; credentials for hosting, domains, app stores and third-party services; and a record of known issues and planned improvements.
A worked example
To make this concrete, here is how the process might look for a mid-sized equipment service company replacing spreadsheets and WhatsApp groups with a field service system.
| Stage | What happened | Key output |
|---|---|---|
| Initial conversations | Two meetings with the owner and service head; agreed the main pain was missed AMC visits and unbilled spare parts. | Problem summary, rough range, discovery proposal |
| Discovery | Interviews with coordinators, five technicians, the store keeper and accounts; collected job sheets, AMC lists and invoice formats. | Scope for release one, workflows, roles, backlog, plan |
| Design | Prototype of the technician app tested with technicians at the depot; dispatcher screens refined with coordinators. | Approved prototypes, technical overview |
| Development | Two-week cycles; jobs and technician app first, then AMC scheduling, then spares and invoicing. | Working features each cycle in the test environment |
| Testing | Coordinators and technicians ran real scenarios, including offline jobs and partial parts usage. | Issue list resolved, acceptance signed |
| Launch | Customers, sites, equipment and AMC contracts migrated; one branch went live first, others two weeks later. | Live system, trained users |
| Support | Daily check-ins for two weeks; then monthly improvement releases. | Stable system, improvement backlog |
Two decisions shaped the project's success. First, the service head was appointed product owner and blocked two hours twice a week for the project. Second, spare-parts invoicing was moved from the first release to the second after discovery showed the store's item codes needed cleaning first — a decision that kept launch on time and gave the store team time to fix their data.
Questions to ask at each stage gate
Before moving from one stage to the next, ask yourself and your development partner:
- After discovery: Do we agree on what release one includes and excludes? Are the assumptions written down? Do we know the main risks and what we will do about them?
- After design: Have real users tried the main flows? Do we understand where the system will run and who controls it?
- During development: Are we seeing working software regularly? Is the backlog honest about what remains? Are we making decisions quickly enough?
- Before launch: Have our users tested the awkward cases? Is data migrated and validated? Do we have a rollback plan and support in place?
- After launch: Do we have the code, documentation and credentials? Is the support arrangement clear? What will we improve next?
The client's checklist
Much of a project's success depends on the client side. Before you start, make sure you can:
- Name a product owner with time and authority.
- Give the development team access to the people who will use the system.
- Share real documents, spreadsheets and data samples early.
- Respond to questions within a day or two.
- Attend demos and try features between them.
- Assign people to clean data and test before launch.
- Accept that the first release will not include everything — and plan for the second.
Summary
The custom software development process is a sequence of steps that reduce uncertainty before committing larger effort: initial conversations to establish fit, discovery to understand the business and agree scope, design to shape the experience and architecture, iterative development with regular demos, user acceptance testing with realistic scenarios, a planned launch with clean data, and long-term support and improvement. At every stage you should receive something concrete and be able to check it. When you know what to expect — and what you are responsible for — you can spot problems early and steer the project towards software your team actually wants to use.
Frequently asked questions
How involved do we need to be during development?
More than most businesses expect. Plan for a product owner on your side who can spend a few hours each week answering questions, reviewing demos and making decisions, with more time during discovery and acceptance testing.
Can we skip discovery if we already know what we want?
You can shorten it, but not skip it. Even clear ideas hide decisions about exceptions, data, permissions and integrations. Discovering those in development is far more expensive than discovering them on paper.
What should we receive at the end of the project?
Working software in production, the source code in a repository you control, documentation for users and administrators, deployment instructions, credentials for all accounts, and an agreed support arrangement.
How do we know the project is on track?
Working features demonstrated regularly, a visible backlog showing what is done and what remains, honest reporting of risks, and acceptance by your users — not percentage-complete estimates.
What happens if we change our minds during development?
Changes are normal. They are discussed, estimated and prioritised against the remaining work. Some replace planned features; others extend the timeline or budget. The key is that the trade-off is made openly.
