Menu

Process

The Custom App Development Process, Stage by Stage

The short answer

Custom app development runs through discovery, design, build, launch and maintenance. Good teams overlap them and repeat the middle ones in short cycles, but the order holds [1] [2].

At every stage the client has work to do: decisions only you can make, and things only you can hand over. Projects most often slip while waiting on the client, so knowing your part in advance is the cheapest way to keep one on track.

Updated November 11, 2026 · 19 sources cited

The stages at a glance

StageThe question it answersIt ends when
DiscoveryShould we build this, and for whom?You can describe the users, the problem and what success looks like
DesignWhat exactly will the first version do?Users have tried a prototype and you've signed off the first release's scope
BuildDoes it work?The first release passes the tests you agreed
LaunchDoes it work for real people, with real data?Users rely on it and problems are rare
MaintenanceDoes it keep working, and what's next?Never, while people depend on it

The UK government's version of this, discovery, alpha, beta and live, is published in full and is worth reading as a neutral reference [1]. The US Digital Services Playbook covers similar ground for American agencies [3].

1. Discovery

Discovery is research before commitment: who the users are, what they're trying to do, how they do it today, and what constraints apply (budget, data, regulation, existing systems). The GOV.UK Service Manual is explicit that discovery shouldn't start building the service [4]. Its output is understanding, not software.

You decide

  • The problem worth solving, in one or two sentences.
  • Who the first users are, and who is out of scope for now.
  • What success looks like, in terms you could check after launch.
  • Whether to proceed at all. Stopping after discovery is a good outcome if the answer is "buy".

You deliver

  • Time with real users and the staff who'd use it.
  • Copies of existing spreadsheets, forms, tools and reports.
  • A named decision-maker who can answer within a day.
  • Known constraints: budget range, deadlines that matter, data rules such as GDPR or HIPAA [5] [6].

2. Design

Design turns needs into a plan you can test: user flows, screens, a data model and a technical approach. The best way to check a design is to put a clickable prototype in front of a handful of real users. Nielsen Norman Group's long-standing advice is that small, repeated rounds of testing with about five users find most usability problems [7]. The UK's equivalent stage, alpha, exists to try out different ideas cheaply [8].

You decide

  • What's in the first release and what waits. Write the "later" list down so it isn't lost.
  • Which platforms: web, iOS, Android, or a combination.
  • Accessibility target; WCAG 2.2 AA is a common one [9].
  • How the build will be priced: fixed price for a defined scope, or time and materials [10] [11].

You deliver

  • Prompt feedback on each prototype round.
  • Brand assets, real content and real sample data, not placeholders.
  • Written sign-off on the first release's scope.

3. Build

During the build the team writes, reviews and tests code in short cycles, usually one or two weeks, and shows you working software at the end of each [2]. You should be able to click through progress, not just read reports about it.

You decide

  • Trade-offs as they surface: cut, simplify or postpone. New ideas go on the "later" list unless something else comes off.
  • Whether each cycle's work is accepted.

You deliver

  • An hour or two every cycle to review and test.
  • Quick answers to questions, so nobody waits.
  • Accounts in your organization's name: the code repository, cloud hosting, domain, email sending and app store developer accounts [12] [13] [14].

4. Launch

Launch moves real users and real data onto the app. Many teams do it in steps: a private group first, then everyone, the way the UK's beta phase runs a service for real users before it's declared live [15]. Mobile apps also need to pass app store review, which follows published rules [16].

You decide

  • The launch date and who goes first.
  • What "ready" means: the tests, the data migration and the support cover that must be in place.
  • How users will report problems.

You deliver

  • Final content, privacy policy and terms.
  • Clean data to migrate, and someone to check it arrived correctly.
  • Training or a short guide for staff.

5. Maintenance

Software in use needs care: security patches, updates when phones and browsers change, fixes, monitoring and improvements. The UK guidance treats "live" as a phase of its own, with continued improvement, not a finish line [17]. Google's site reliability guidance suggests monitoring a few user-facing signals, such as latency, traffic, errors and saturation, rather than everything [18].

You decide

  • Who maintains it: the team that built it, another partner, or your own staff.
  • Response times you need for urgent and minor problems, written into an agreement [19].
  • What gets built next, reviewed every month or quarter.

You deliver

  • An owner on your side who keeps the priority list.
  • Budget for upkeep, agreed before launch.
  • Up-to-date admin access for everyone who should have it, and removal for those who've left.

What a good support arrangement includes is set out in How to choose a development partner.

Worked example

Worked example

A clinic's appointment requests

The situation
An illustrative scenario: a small clinic wants patients to request appointments online instead of phoning. In discovery, the team learns most calls are about rescheduling, not new bookings.
The decision
The first release handles rescheduling and cancellations only. Because it touches health information, the design stage includes a review of the clinic's obligations under the applicable health privacy rules [6].
What to take from it
Discovery changed what got built. Skipping it would have produced the wrong first release, built well.

Questions people ask

What are the stages of custom app development?

Discovery, design, build, launch and maintenance. The UK government calls its version discovery, alpha, beta and live [1].

How involved does the client need to be?

Closely. Plan on a named decision-maker who reviews work every cycle and answers questions quickly; agile methods assume business people and developers work together daily [2].

Can I skip discovery to save money?

You can, but you'll be paying to build on guesses. A short discovery is the cheapest point to change direction, or to learn you should buy instead [4].

Who should own the app store and hosting accounts?

Your organization. Set them up in its name from the start [13] [14] and give the team access, so a change of partner never means losing the app.

Custom App, No-Code or Off-the-Shelf: How to DecideA decision framework for custom builds, no-code tools, AI-generated MVPs and existing software, and when each stops working.How to Choose a Development PartnerFreelancers, agencies, product studios and in-house hires compared, with questions to ask, red flags and what ongoing support should include.What Drives Cost and TimelineThe factors that move scope, budget and schedule, and how to write a brief that gets comparable proposals.

Sources

Every numbered claim on this page links here. Each source is public; follow the link to check it.

  1. Agile delivery: phases of a service, GOV.UK Service Manual
  2. Manifesto for Agile Software Development, agilemanifesto.org
  3. Digital Services Playbook, U.S. Digital Service
  4. How the discovery phase works, GOV.UK Service Manual
  5. Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex
  6. HIPAA for Professionals, U.S. Department of Health and Human Services
  7. Why You Only Need to Test with 5 Users, Nielsen Norman Group
  8. How the alpha phase works, GOV.UK Service Manual
  9. Web Content Accessibility Guidelines (WCAG) 2.2, W3C
  10. Fixed-price contract, Wikipedia
  11. Time and materials, Wikipedia
  12. Transferring a repository, GitHub Docs
  13. D-U-N-S Number (enrolling as an organization), Apple Developer
  14. Google Play Console, Google
  15. How the beta phase works, GOV.UK Service Manual
  16. App Review Guidelines, Apple Developer
  17. How the live phase works, GOV.UK Service Manual
  18. Monitoring Distributed Systems (Site Reliability Engineering), Google
  19. Service-level agreement, Wikipedia