Business · 5 min read
The Custom Software Development Process: What to Expect
Discovery to rollout, stage by stage, and the four things the client controls that decide whether a project lands.
Share
Key takeaways
- A custom software project runs through discovery, design, build, testing, migration, and rollout, each with a realistic minimum length.
- Discovery should surface the exceptions in your process, because that is where generic software fails and budgets get blown.
- You should see working increments every one to two weeks; months of invisible progress is a warning sign.
- The client controls four things that decide the timeline: one decision-maker, early access, honest process descriptions, and time for testing and training.
- Insist in writing that you own the code and data, and confirm what happens after launch.
A custom software project runs through six stages: discovery, design, build, testing, migration, and rollout. Knowing what happens in each one, and what is expected of you, is the difference between a project that lands and one that drifts.
Most software disappointments are not technical. They come from mismatched expectations about who decides what and when. This is what a well-run project actually looks like from the client side.
What are the stages of a custom software project?
| Stage | Typical length | What you do | What you get |
|---|---|---|---|
| Discovery | 1 to 3 weeks | Explain workflows, answer questions | A written scope and a plan |
| Design | 2 to 4 weeks | Review screens, approve flows | Screens you can click through |
| Build | 4 weeks to months | Review increments | Working software, in stages |
| Testing | 2 to 4 weeks | Try it with real cases | A fixed, verified system |
| Migration | 1 to 4 weeks | Clean and confirm your data | Your records in the new system |
| Rollout | 1 to 3 weeks | Train the team, switch over | A system in daily use |
What happens during discovery?
Discovery maps how the work is done now: who touches the process, what they enter, where it goes, what breaks, and what the exceptions are. The exceptions matter most, because they are where generic software fails and where budgets get blown.
Expect to be asked uncomfortable questions. Why does that approval exist? What happens when the manager is away? How often does that actually occur? A developer who does not ask these is going to build the happy path and miss the real business.
What you should get at the end is a written scope: what is included, what is explicitly excluded, and an estimate you can hold someone to. If it is verbal, it is not a scope.
What happens during design?
Screens and flows, agreed before anyone writes production code. This is the cheapest point to change your mind, and the moment when vague requirements become concrete.
Your job here is to react honestly. "That is not how we do it" is the most valuable sentence in the project, and it costs almost nothing in design. The same sentence after the build costs days.
What happens during the build?
Work is delivered in increments you can see, usually every one to two weeks. You should be able to open something and click around long before launch. If months pass with no visible progress, that is a warning sign regardless of the explanation.
Expect questions to keep arriving. Real building surfaces decisions nobody anticipated: what happens if a record is deleted after approval, what a report should show when data is missing. Answering these quickly is the single biggest thing you control.
What happens during testing and migration?
Testing is where real cases meet assumptions. Your team should try to break it using awkward, realistic scenarios rather than tidy ones. Every bug found here is one your staff will not hit in front of a customer.
Migration is moving existing records in. This is consistently underestimated because old data is messy: inconsistent formats, duplicates, records with missing fields nobody noticed. Cleaning it is business work as much as developer work, and it is worth starting during discovery.
There is more on what stretches these phases in how long custom software takes to build.
What is expected of you as the client?
Four things, and the project depends on them more than on the developers.
One decision-maker who can answer within about two working days. Projects run at the speed of their slowest approval.
Access, early. Credentials, accounts, and permissions on day one rather than week six.
Honest process descriptions. Describe how the work is really done, including the workarounds. A project built on the official process rather than the real one will not fit.
Time for testing and training. Both get squeezed when a date slips, and both are what determine whether people actually use the thing.
What should you insist on in the contract?
You should own the code and the data, in writing. You should get the repository, the credentials, and a deployment that does not depend on one person's laptop. You should know what happens after launch: what maintenance covers, response times, and cost.
How to read web design contract clauses that protect you covers the wording, and the website handover checklist covers what should be delivered at the end.
What should you do next?
Before approaching anyone, write one page: the process you want to change, who touches it, what breaks today, and what a good outcome looks like. That page shortens discovery, makes estimates more accurate, and tells you quickly whether a development partner is listening.
If you would rather talk it through first, book a call.
Related service
Web design services in the PhilippinesFrequently asked questions
What are the stages of a custom software project?
Discovery (1 to 3 weeks), design (2 to 4 weeks), build (4 weeks to several months), testing (2 to 4 weeks), data migration (1 to 4 weeks), and training and rollout (1 to 3 weeks). Each stage has a realistic minimum, and skipping one usually moves the cost rather than removing it.
What is expected of me as the client?
Name one decision-maker who can answer within about two working days, provide access and credentials early, describe how the work is really done including workarounds, and protect time for testing and training. Projects run at the speed of their slowest approval.
How often should I see progress?
You should be able to open and click through working software every one to two weeks during the build. If months pass with nothing visible, treat that as a warning sign regardless of the explanation given.
What should the contract cover?
That you own the code and the data, that you receive the repository and credentials, that deployment does not depend on one person's machine, and what happens after launch including maintenance scope, response times, and cost.
Let's build something
great together
Have a project in mind? We'd love to hear about it and explore how we can help bring your vision to life.
Get in touch