For many UK business owners and directors, the custom software development process feels like a black box. You brief an agency, some technical things happen for several months, and eventually a piece of software appears. What goes on in between — and, crucially, what your role is throughout — remains largely mysterious.
That mystery is costly. Businesses that commission custom software without understanding the process tend to underinvest in the stages that matter most (discovery and testing), overestimate the development team’s ability to read their minds, and then wonder why the delivered product does not quite match what they imagined.
This guide removes the mystery entirely. We walk through every stage of the custom software development process in plain English — what happens, who is responsible, what you need to contribute, and how long each phase typically takes. By the time you finish reading, you will know exactly what to expect if you commission bespoke software, and you will be far better placed to manage the process well.
How Many Stages Are There?
The custom software development process is typically structured across seven stages, though different agencies may use different terminology or group certain phases together.
Here is the full sequence:
Stage 1 → Discovery & Requirements Stage 2 → Planning & Architecture Stage 3 → UI/UX Design Stage 4 → Development (Build) Stage 5 → Testing & Quality Assurance Stage 6 → Deployment & Launch Stage 7 → Ongoing Maintenance & Support
Total timeline for a mid-complexity business system typically runs 16–28 weeks from kickoff to go-live. Simpler tools can be delivered in 8–12 weeks. Large enterprise platforms can take 12 months or more.
The single biggest variable? How well requirements are defined in Stage 1. Everything that follows is only as good as the foundation laid there.
Stage-by-Stage Breakdown
Stage 1 — Discovery & Requirements Gathering
Duration: 1–3 weeks Output: Scope document / functional specification
This is the most important stage of the entire process, and the one most commonly underestimated by clients.
Discovery is where your business needs are translated into a technical specification. A good development partner will run structured workshops or interviews with you and your key stakeholders — asking not just what you want the software to do, but why, and how your current processes work in practice.
The output is a detailed document — variously called a functional specification, scope document, or product requirements document — that describes exactly what the software will do, who will use it, what data it will handle, and how it will integrate with other systems.
Your role at this stage: Active and engaged. The discovery phase only works if you invest the time. You will be asked to walk through your current processes in detail, identify pain points, prioritise functionality, and make decisions about what is in and out of scope. If you approach discovery passively, the specification will be incomplete — and an incomplete specification is the single most common cause of project overruns and disappointing outcomes.
What to prepare: Document your current processes before discovery begins. Gather examples of reports you currently produce manually, forms your team fills in, data structures you rely on, and integrations with other systems. The more prepared you are, the more productive discovery will be.
Stage 2 — Planning & Architecture
Duration: 1–2 weeks Output: Technical architecture document, project plan, resource allocation
Once requirements are defined, the development team plans how to build what has been specified.
This involves selecting the appropriate technology stack (the programming languages, frameworks, databases, and infrastructure that will underpin the software), structuring the system architecture, assembling the development team, and producing a project plan with milestones and delivery dates.
Your role at this stage: Largely consultative. You may be asked to confirm infrastructure preferences — for example, whether you have a preference for cloud hosting provider, or whether on-premises deployment is a requirement. You will also review and sign off the project plan, which commits both parties to timelines and key milestones.
What to look for: A credible technical architecture document, a realistic timeline with clearly defined milestones, and explicit clarity on who is responsible for what. Be cautious of agencies that rush through planning or produce vague project plans — ambiguity here creates conflict later.
Stage 3 — UI/UX Design
Duration: 2–4 weeks Output: Wireframes, interactive prototypes, approved design specifications
Before any code is written, the user interface and user experience are designed. This typically begins with low-fidelity wireframes — simple structural layouts showing where content and functionality will appear — before progressing to high-fidelity prototypes that look and feel close to the finished product.
Good UX design is not merely about aesthetics. It is about ensuring that users can accomplish their goals efficiently, with minimal friction and without requiring extensive training. For internal business tools especially, this investment pays dividends in adoption rates.
Your role at this stage: Review and feedback. You will be presented with design iterations and asked to give structured feedback. Be specific and concrete in your responses — “this does not feel right” is not actionable, but “the approval workflow should appear at the top of the screen rather than below the data table, because that matches how our team prioritises decisions” is.
This is also the point at which changes are cheapest to make. Altering a design in a prototype costs hours. Altering the same element after it has been built costs days. Use this stage generously.
Stage 4 — Development (Build)
Duration: 6–24 weeks depending on complexity Output: Working, tested software increments delivered progressively
This is the stage most people think of as “the development” — where engineers actually write the code. For anything more than the simplest tool, this phase is structured using an agile methodology, specifically a framework called Scrum.
What agile means in practice (in plain English): Rather than building everything and delivering it all at once at the end, the development team works in short, fixed cycles called sprints — typically one or two weeks long. At the end of each sprint, they demonstrate the working software built during that period. You review it, give feedback, and the cycle continues.
This approach has significant advantages over traditional “waterfall” development. Problems are caught early, when they are still cheap to fix. You get visibility into progress throughout rather than only at the end. And requirements can be refined as the project evolves — because even the best discovery process cannot anticipate every detail.
Your role at this stage: Attend sprint review sessions, provide timely feedback, and make decisions promptly when the development team needs direction. Delayed decisions are one of the most common causes of sprint disruption and project delays — a question left unanswered for a week can block an entire development thread.
What to watch for: A healthy agile project has regular, working demos. If your development partner is consistently unable to demonstrate progress at sprint reviews, or if they frequently cite “technical issues” without clear resolution plans, those are signals worth probing.
Stage 5 — Testing & Quality Assurance
Duration: 2–4 weeks (overlaps with development in agile projects) Output: Verified, signed-off software ready for deployment
Testing is not a single event that happens at the end of development — in a well-managed project, it is continuous. QA engineers test each increment of software as it is built, identifying and logging defects (bugs) for the development team to fix.
As the project approaches completion, formal testing phases take place:
Functional testing confirms that every feature works as specified. Security testing identifies vulnerabilities in the code and infrastructure. Performance testing confirms the software performs acceptably under realistic load — for example, that it does not slow to a crawl when 200 users access it simultaneously. User Acceptance Testing (UAT) is where you and your team test the software in a staging environment, confirming it meets your requirements before it goes live.
Your role at this stage: UAT requires genuine engagement from your side. Assemble a representative group of end users, provide them with test scenarios based on real tasks they perform, and document any issues they encounter. UAT is not about finding things you do not like aesthetically — it is about confirming that the software does what it was specified to do.
Stage 6 — Deployment & Launch
Duration: 1–2 weeks Output: Live software, deployed to production environment
Deployment is the process of moving the software from its development or staging environment to the live production environment where real users will access it.
This includes final infrastructure configuration, data migration (if you are moving data from existing systems), DNS changes, security hardening, and monitoring setup. A go-live checklist should be agreed in advance between you and the development team.
There are two common deployment approaches: a full launch, where all users switch to the new system simultaneously, and a phased rollout, where the software is introduced to a pilot group first before wider roll-out. For business-critical systems replacing existing processes, a phased approach significantly reduces operational risk.
Your role at this stage: Ensure staff training is complete before go-live. Designate internal champions who understand the new system and can support their colleagues during the transition. Agree a clear escalation process for issues arising immediately post-launch.
Stage 7 — Ongoing Maintenance & Support
Duration: Indefinite Output: Continued security, performance, and feature development
This is the stage that is most frequently overlooked during the commissioning process — and one of the most consequential. Software does not maintain itself.
Post-launch, your software will require ongoing attention: security patches as new vulnerabilities are identified, compatibility updates as underlying technologies evolve, infrastructure management, and periodic performance optimisation. Beyond maintenance, most businesses develop a feature roadmap — a prioritised list of enhancements and new capabilities to be built over time.
Agree a support and maintenance arrangement with your development partner before the project starts, not after go-live. Define response times for critical issues, what is included in ongoing maintenance, and how future development work will be scoped and priced.
What Can Go Wrong — and How to Prevent It
The majority of custom software projects that go over budget, over time, or under-deliver share a small set of common failure modes.
Poor requirements definition is the most prevalent. If what you are building is not clearly specified at the outset, it cannot be built accurately. Invest generously in the discovery phase. Do not rush it to save time or money — it is the cheapest opportunity you will ever have to get the project right.
Scope creep occurs when additional features and requirements are added mid-project without formal change control. Every addition seems small in isolation; cumulatively, they can double a project’s duration. Insist on a formal change request process and understand the cost and timeline implications of every scope change before approving it.
The wrong development partner is a risk that due diligence can largely mitigate. Ask for case studies from businesses of similar size and complexity to yours. Speak to reference clients. Understand who will actually work on your project — not just who pitches for it.
How to Choose the Right Development Partner in the UK
When evaluating UK software development agencies, ask these questions directly:
- Who specifically will work on our project, and what is their experience?
- Can you provide two or three reference clients we can speak with?
- How do you handle scope changes — what is your change control process?
- What does your post-launch support arrangement look like?
- Who owns the codebase at the end of the project?
- What happens if the relationship breaks down mid-project?
Look for agencies with published case studies showing real client outcomes, transparent pricing models, and clear contract terms around intellectual property ownership. Industry bodies such as TechUK and peer review platforms such as Clutch can provide useful additional context when assessing credentials.
Related Reading: Complete Your Knowledge Before You Commit
Understanding the development process is essential — but it is one piece of a larger decision. Before commissioning any custom software, we recommend building your understanding across our full series:
- What custom software actually is — if you are still clarifying the fundamentals, start with What Is Custom Software Development? A Plain-English Guide for Businesses in 2026. It covers definitions, types of custom software, and common misconceptions in plain English.
- Whether the benefits apply to your business — not every advantage of custom software applies to every organisation. Our guide 10 Key Benefits of Custom Software Development (And When They Actually Matter) gives you an honest, nuanced breakdown of each benefit alongside an honest “when it matters” assessment.
- The broader build-vs-buy decision — if you are still weighing custom development against off-the-shelf alternatives, Custom Software vs Off-the-Shelf Software: Which Is Right for UK Businesses in 2026? provides a comprehensive, UK-specific comparison covering costs, GDPR, scalability, and a practical decision framework.
Read across all four articles and you will have a thorough, unbiased foundation for one of the most consequential technology decisions your business can make.
FAQs
How long does the custom software development process take?
Timeline depends on scope and complexity. A focused, well-specified tool can be delivered in 8–12 weeks. Mid-complexity business systems typically take 3–6 months. Large enterprise platforms may take 12 months or more. The biggest determinant of timeline is the quality of the discovery phase — poorly defined requirements are the leading cause of delays.
What is my role as a client during development?
More active than most clients expect. You are responsible for: providing clear, detailed requirements during discovery; giving timely, specific feedback during design; attending sprint reviews during development; organising and actively participating in UAT; and making decisions promptly when the development team needs direction. Passive clients consistently produce worse outcomes.
What is agile development and do I need to understand it?
Agile is an iterative approach to software development where work is completed in short cycles (sprints) and demonstrated to the client progressively, rather than delivered all at once at the end. You do not need a deep technical understanding, but you do need to engage with the sprint review process — attending demos, giving structured feedback, and making decisions. Think of it as a series of fortnightly check-ins where you can see exactly what has been built.
How much input do I need to give at the discovery stage?
Significant input. Discovery requires you to document and articulate your business processes, data requirements, integration needs, user roles, and priorities in detail. The quality of your input directly determines the quality of the specification — and the quality of the specification directly determines the quality of the final software. Treat discovery as the highest-leverage investment of time you will make in the entire project.
What should a contract with a UK software development agency include?
At minimum: a clearly defined scope with change control provisions, intellectual property ownership terms (confirming the codebase transfers to you on completion), payment milestones tied to deliverables, confidentiality provisions, post-launch support terms, and a dispute resolution mechanism. Have a solicitor review any significant contract before signing.
