The custom software development process is the sequence of stages that turns a business problem into working software and keeps it working: discovery, requirements, design, architecture, development, QA, deployment, monitoring, maintenance and iteration. Knowing what each stage should produce is the simplest way to tell a well-run project from one that is about to drift.
This guide looks at each stage from the client’s side of the table: what happens, what you receive, what only you can decide, and the mistake we see most often. If your question is how long each stage takes, read how long custom software development takes instead; this guide deliberately leaves the durations there.
What is the custom software development process?
In short: it is the software development lifecycle (SDLC) applied to one project. Ten stages: the first seven get a release live, the last three keep it useful.
The textbook name is the software development lifecycle. In practice the stages overlap: design for module two can happen while module one is being built. What should not overlap or be skipped is the gate at the end of each stage, the point where a deliverable is checked before the next stage relies on it.
The custom software development lifecycle
- DiscoveryThe problem, the success measure and a scoped plan
- RequirementsA prioritised backlog and a clear in/out list for release one
- UX/UI designA clickable prototype tested by your own team
- ArchitectureTechnology, data model, hosting and integrations decided
- DevelopmentWorking software, demonstrated every week
- QAAutomated tests, manual testing and user acceptance testing
- DeploymentData migration, go-live, training
- MonitoringAlerts, logs and tested backups
- MaintenanceSecurity patches, updates and fixes
- IterationMeasure results, then plan the next slice
Discovery: what problem are we solving?
In short: discovery turns “we need a system” into a specific problem, a measurable goal and a first release small enough to ship.
Engineers learn how the work is done today: who touches it, where it goes wrong and what that costs. They look at the spreadsheets, the shared inbox and the tools you already pay for, and decide which to keep and connect rather than replace. Sometimes the honest answer is that a packaged tool will do; our comparison of custom software vs off-the-shelf software covers that decision.
You receive: a written scoped plan with a price range and timeline (at DataVolve, within 24 hours of the first call), a statement of what release one includes, and how success will be measured.
You decide or provide: the numbers behind the problem (hours spent, enquiries lost, errors made), the list of tools you use, and one named person who will make decisions for the project.
Common mistake: starting with a feature list instead of a problem. “We need a dashboard” leads to a dashboard. “We cannot see which jobs lose money” leads to the right software.
Requirements: what exactly will release one do?
In short: requirements turn the scope into a prioritised list of things the software must do, each with a test that defines “done”.
Requirements are usually written as user stories with acceptance criteria. For example: “As a sales manager, I want overdue follow-ups flagged each morning so that no enquiry goes cold”, plus the conditions that prove it works. This stage also pins down the user roles and what each can see or approve, the data that moves in and out, and every system the software must connect to.
You receive: a prioritised backlog with acceptance criteria, an explicit in/out list for release one, a roles and permissions matrix, and an inventory of data sources and integrations.
You decide or provide: what is out of release one, sample real data (anonymised where needed), access to the systems being integrated, and the business rules nobody has written down, such as pricing tiers, discount limits and who approves what.
Common mistake: leaving “obvious” rules unwritten. The rule everyone in the office knows is the one most likely to be missing from the backlog.
UX/UI design: will people actually use it?
In short: design produces a clickable prototype your team tests before any code is written, the cheapest point at which to find a mistake.
Designers map the user flows (the path through each task) and then the screens. For internal software, the priority is fewer clicks on the tasks people repeat all day. For customer-facing software, clarity and brand matter more.
You receive: a clickable prototype of the main flows and a consistent set of screen components and styles that the whole system will reuse.
You decide or provide: the people who will use it every day to click through and comment, your brand assets, and sign-off on the flows.
Common mistake: only managers review the prototype. The coordinator who processes orders all day will spot in five minutes what a director never would.
Architecture: how will it be built and where will it run?
In short: architecture settles the technology, data model, hosting and integration approach, the choices that are expensive to change later.
This is where the team designs how data is stored and related, where the system is hosted, how integrations work (live or scheduled), how people log in, and which environments exist (development, staging, production). Security controls are designed here too: role-based access, audit logs, encryption and backups. We use proven technology (React, Node.js, Python and AWS for web; React Native and Flutter for mobile), so no single supplier is needed to maintain it.
You receive: a short architecture outline in plain language, and the code repository, cloud account and domain set up in your name from the first commit.
You decide or provide: the hosting region (for example, a UK region if that matters for your UK GDPR position), who in your business holds admin access, and whether standard services for login, e-mail delivery or payments are acceptable instead of custom ones.
Common mistake: letting the supplier own the cloud account and repository “for convenience”. It quietly turns a supplier into a lock-in.
Development: building in small, visible increments
In short: development delivers working software in short cycles, with a demo every week so you can steer while change is still cheap.
Engineers build the backlog in priority order. Each change is reviewed by another engineer, covered by automated tests and deployed to a staging copy you can use. The highest-value slice goes live first rather than waiting for everything to be finished.
You receive: a weekly demo of working software (not slides), access to the staging system, a visible backlog showing what is done and what is next, and code that sits in your repository throughout.
You decide or provide: half an hour a week at the demo, answers to questions within a day, and clear choices when priorities change. Swap items in and out; do not just add.
Common mistake: treating the demo as optional. A misunderstanding caught in week two is a small fix. The same one found at the end is a rebuild. Asking to see a real demo is also one of the best tests when choosing a software development company.
QA: proving it works before your customers do
In short: quality assurance combines automated tests, manual testing and user acceptance testing. Nothing is released until agreed criteria pass.
Automated tests run on every change. Testers then work through edge cases by hand, check roles and permissions (can a junior user approve beyond their limit?), test integrations against the other systems’ test environments, and check performance where volume matters. Finally your own staff run user acceptance testing (UAT) on staging, using real scenarios.
You receive: a test plan tied to the acceptance criteria, UAT scripts, a defect log ranked by severity, and a release-readiness summary.
You decide or provide: testers from the team that will use the system, with time blocked out; the awkward real-life scenarios (the customer with two accounts, the refund after invoicing); and the final go or no-go decision.
Common mistake: running UAT with tidy, made-up data. Real data finds real bugs.
Deployment: going live without disrupting the business
In short: deployment moves the software and your data into daily use, with a rollback plan, training and close support in the first weeks.
The production environment and automated release pipeline are configured, a trial data migration is run and checked, and then the final migration and cut-over from the old system take place. Staff are trained, and the team watches the system closely for the first days or weeks. Mobile apps also go through app store review at this stage.
You receive: a go-live plan with cut-over and rollback steps, a migration report (records moved, records rejected and why), training sessions or short guides, handover documentation, and admin access.
You decide or provide: a go-live date away from your busiest period, the date the old system becomes read-only, the message to staff, and sign-off that the migrated data is right.
Common mistake: running old and new systems side by side with no end date. Double entry is the fastest way to kill adoption.
Monitoring: knowing about problems before users report them
In short: monitoring watches uptime, errors, performance, integrations and backups, so issues are fixed before they become support calls.
That means uptime checks, error tracking, logs, alerts when an integration fails (for example, an overnight sync to your accounting package), cloud cost monitoring, and regular test restores of backups.
You receive: configured alerts, access to the logs and dashboards, and an agreed route for reporting and handling incidents.
You decide or provide: who in your business is told about incidents, and what counts as urgent. Checkout being down is urgent; a slow monthly report usually is not.
Common mistake: assuming backups work because they are scheduled. A backup that has never been restored is a hope, not a backup.
Maintenance: keeping the software secure and working
In short: maintenance covers security patches, dependency updates, fixes and small changes. Budget 15–25% of the build cost a year.
Software does not stand still around you. The libraries it uses receive security updates, browsers and phone operating systems change, third-party services retire old versions of their APIs, and real use surfaces bugs no test predicted.
You receive: regular updates and patches, fixes within agreed response times, and compatibility updates for mobile apps.
You decide or provide: a maintenance budget (typically 15–25% of the build cost a year, plus hosting of around £15–£250 or $20–$300 a month) and support terms in writing. Our UK custom software development cost guide breaks down these running costs.
Common mistake: no maintenance budget at all. Unmaintained software does not stay the same; it slowly breaks.
Iteration: measuring results and building the next slice
In short: iteration compares results with the success measure set in discovery, then decides what to build next, or whether to stop.
The team reviews usage and the original numbers: hours saved, enquiries followed up, errors removed. User feedback and the parked release-two list are reprioritised, and the lifecycle starts again at a smaller scale.
You receive: a review of results against the success measure and a proposed next release with scope, price and timeline.
You decide or provide: what to build next. Sometimes the right answer is that the software is done for now.
Common mistake: building release two from the wish list written before launch, instead of from what users actually did.
Deliverables and quality gates at a glance
In short: every stage should end with something you can see and a check before the next stage relies on it.
| Stage | You receive | Gate before moving on |
|---|---|---|
| Discovery | Scoped plan, price range, timeline | Problem, success measure and first release agreed |
| Requirements | Prioritised backlog, in/out list, roles matrix | Release-one scope signed off |
| UX/UI design | Clickable prototype | Real users have tested the main flows |
| Architecture | Architecture outline; repository and cloud account in your name | Hosting, data model and integrations agreed |
| Development | Working software, weekly demos | Features meet acceptance criteria on staging |
| QA | Test results, defect log, UAT sign-off | No open critical defects; go/no-go agreed |
| Deployment | Go-live plan, migration report, training, handover | Migrated data checked; rollback plan ready |
| Monitoring | Alerts, logs, tested backups | Incident route and contacts agreed |
| Maintenance | Updates, patches, fixes | Budget and support terms in writing |
| Iteration | Results review, next-release plan | Next release chosen from real usage |
Where does security fit in the process?
In short: security is not a stage. It belongs in every stage, from requirements to maintenance.
The US National Institute of Standards and Technology’s Secure Software Development Framework (NIST SP 800-218) describes a core set of high-level secure development practices designed to be integrated into each SDLC. Its aims are to reduce vulnerabilities in released software, limit the impact of any that slip through, and fix root causes so they do not recur. In a business software project, that looks like this:
- Requirements: identify the sensitive data and who may see it.
- Architecture: role-based access, encryption, audit logs and a deliberate hosting region.
- Development: code review, dependency checks, and passwords and keys kept out of the code.
- QA: test permissions and common attack paths, not just the happy path.
- Maintenance: patch promptly, and have a way to receive and fix reported vulnerabilities.
Our guide to custom business software security covers what to ask for and check in more detail.
Agile, Scrum or waterfall: which software development methodology?
In short: most business software is best built with a fixed first release delivered in weekly cycles. Pure waterfall suits only requirements that are stable and fully known.
Waterfall runs the stages once, in order: all requirements, then all design, then all development, then testing. It is predictable on paper, but you see working software only near the end, which is when change is most expensive.
Agile methods run the lifecycle in short loops. The Agile Manifesto values “working software over comprehensive documentation” and “responding to change over following a plan”. Scrum, the best-known agile framework, organises work into Sprints, which the Scrum Guide defines as fixed-length events of one month or less, each ending with a review of what was built.
We use a hybrid. Release one gets a fixed, written scope and price so both sides commit to something concrete; it is built in weekly cycles with a demo each week; after launch, work becomes iterative. The label matters less than the habits: small releases, visible progress and one decision owner. Whether you run this process with your own hires or an outside team, the in-house vs outsourced development cost calculator compares what each costs.
If you want this process applied to your own project, see how we run custom software development for UK and US businesses: a written plan within 24 hours, a clickable prototype before code, weekly demos, and the code, cloud account and domain in your name from the first commit.