The custom software development process is a sequence of decisions more than a sequence of tasks. You write a brief, agree a written scope, approve a design, watch the build in increments, accept the result against agreed checks, launch, and take over the code and accounts. Most guides describe what the vendor does. This one describes what you provide, decide and receive at each step, so you can tell whether a project is on track.
The custom software development process at a glance
Sources slice the work differently. AWS lists six SDLC stages: plan, design, implement, test, deploy and maintain. Adevs describes seven phases, from discovery and requirements through design, development, testing, deployment and maintenance to evolution and scaling. Keyhole also uses seven. The names differ, the content is the same.
Keyhole adds a point worth keeping: the phases overlap. They are not rigid handoffs or approval gates, quality assurance runs continuously, and requirements keep evolving during implementation. A good project still has fixed points where you decide something. Those are the steps below.
| Step | You provide | You decide | You receive |
|---|---|---|---|
| Brief | The problem, users, constraints | What success looks like | Questions back, not a quote yet |
| Discovery and scope | Access to people and systems | What is in and out | Written scope, milestones, estimate |
| Design | Feedback on flows | Which design to build | Prototype, technical approach |
| Build | Answers within days | Priorities per increment | A demo and a running build each cycle |
| Acceptance | Test users, real data | Accept or reject | Test results, known issues list |
| Launch | Go or no-go | Launch approach | Production system |
| Handover | Named owner on your side | Support model | Code, accounts, documentation |
Step 1: Write the brief before you call anyone
A brief is one or two pages. It names the problem in the words your team uses, who will use the software, what it must connect to, and what you already tried. It also lists constraints: a date, a regulation, a system you cannot replace.
Codeit stresses that the customer’s active participation in every stage is half of success. The brief is the first place that shows. A vendor who cannot restate your problem after reading it is not ready to scope it. For help comparing vendors at this point, see our twelve questions for choosing a software development company.
Step 2: Discovery and the written scope
Discovery turns the brief into something that can be estimated: requirements, risks, integrations, and a list of what is out of scope. Keyhole notes that depth varies with the organisation. Formal enterprises run longer discovery, while smaller product-led teams with empowered decision-makers can run shorter ones.
The output you should hold is a written scope. It lists features by name, integrations by name, milestones with dates, and the assumptions behind the estimate. If any of those are missing, the estimate is a guess. If the idea is still unproven, a smaller first release may be the better opening; our guide to building an MVP in eight weeks shows how that scope is cut.
Step 3: Design decisions that are hard to reverse
Design covers the interface and the technical approach. Inside the custom software development process most choices can change later. A few cannot change cheaply, and you should ask to see them written down:
- The data model. How records relate to each other shapes every later feature.
- Integrations. Which systems the software reads from and writes to, and who owns those connections.
- Hosting and accounts. Where the software runs and in whose name the accounts are registered.
- Security and privacy approach. Who can see what, and how personal data is handled.
Ask the studio which of these are settled at this point and which are open. For how the stages are named and what each produces, see our article on the seven stages of app development.
Step 4: Build in increments you can see
Keyhole describes the common rhythm: fixed cycles, most often two weeks, each producing tested software that could be deployed. Planning puts the highest-risk and highest-value work first, not the easiest. That order matters to you. In any custom software development process, front-loading risk means problems appear in week two instead of week twelve.
What you should see after each cycle is a short recorded demo and a running build on a staging address. What you owe in return is answers within days. A project stalls more often on waiting for decisions than on waiting for code. Name one person on your side who can say yes.
How change requests enter the custom software development process
New ideas will arrive. In the three vendor guides we checked in detail (Adevs, Keyhole, Codeit), the phrase “change request” does not appear once. That is a gap, because this is where scope drifts.
Here is a workable rule, and the one we recommend. Every new idea is written down, sized against the current scope, and answered with three options: swap it for something already planned, add it with a new milestone and a revised estimate, or park it for the next release. Nothing enters the build on a chat message. Whatever studio you choose, ask to see its version of this rule before you sign.
Step 5: Testing and acceptance
Testing runs through the whole custom software development process, but acceptance is a separate act. It is you, or your users, trying the software on realistic data and confirming that what was agreed works.
Write acceptance criteria as checks anyone can run: “a signed-in user creates an order and the warehouse sees it on the next refresh.” Keep a known issues list rather than pretending there are none. Accepting with a short list of agreed leftovers is normal. Accepting without a list means you did not look.
Step 6: Launch, in one of four ways
Keyhole names four deployment approaches. The right one depends on how critical the system is and how much disruption you can tolerate.
| Approach | How it works | Fits when |
|---|---|---|
| Phased rollout | Release to a pilot group, monitor, then expand | Many users, customer-facing systems |
| Parallel operation | Run old and new systems side by side | Mission-critical systems with complex data |
| Blue-green | Two production environments, switch traffic after validation | Cloud-native systems that need minimal downtime |
| Cutover | Planned window, migrate, switch at a set time | Clear boundaries and tolerance for planned downtime |
Keyhole also calls data migration often the highest-risk activity at this stage. Ask early where your existing data lives, how it will be checked after the move, and how you would roll back.
Step 7: Handover and life after launch
Keyhole calls custom software a long-lived asset, not a one-time deliverable. A custom software development process that stops at launch is incomplete. The project is finished when you hold what you need to run it:
- The source code in a repository your organisation owns.
- The hosting, domain and third-party accounts, registered to you.
- Documentation: how to deploy, where the secrets live, how data is backed up.
- A support model for after launch, in writing.
If any of these stay with the vendor, you have bought a dependency. Our custom software development page describes how we work.
Send the brief, get a written scope
techcraftz puts scope, milestones and the estimate in writing before the first line of code, then hands over the code, the accounts and the keys. If you are about to start, send the brief and ask for a written scope. You can also read more about techcraftz.
Last checked: October 14, 2026. Phase names and rollout approaches come from the cited sources and vary by vendor.
Talk to us about your project
Tell us what you need. We help you scope the build, the milestones and a realistic estimate.
View services
