Softomate Solutions is a London-based mobile app development company that has taken UK businesses through this process dozens of times. Building a mobile app is one of the most significant technology investments a business can make, and it goes wrong more often than it should. Not because the technology is too hard, but because the process around it is poorly managed. This guide walks through every stage, what it costs, how long it takes, and what separates projects that succeed from those that do not.
A professional mobile app development process has seven stages: discovery and strategy, wireframing and UX, visual design, development sprints, quality assurance and testing, App Store and Play Store submission, and post-launch. Skipping or compressing any of these stages does not accelerate the project; it transfers risk from the early stages where changes are cheap to the late stages where changes are expensive. Understanding each phase helps you engage productively with your development partner and hold them accountable to a process that actually works.
Discovery is the most undervalued phase of mobile app development and the one most often cut when budgets are squeezed. It is also the one that has the largest single impact on project outcomes. A proper discovery phase takes two to five weeks and costs ยฃ5,000 to ยฃ18,000 for a UK business app. What you get is a detailed specification, a realistic cost estimate, and a shared understanding between your business and your development partner about what is being built and why.
During discovery, the development team learns your business model, your target users, your competitive landscape, and your technical constraints. They map the user journeys your app needs to support, identify the integrations required with existing systems, and surface any technical risks early when they can be addressed in the design rather than in the code. A good discovery phase produces: a functional specification describing what the app does and does not do; user stories written from the perspective of each user type; a prioritised feature backlog; a technical architecture overview; and a realistic project timeline and budget.
Discovery also serves as a quality filter. A development partner who conducts a thorough discovery gives you genuine insight into how they think and communicate. If their discovery output is vague, generic, or fails to reflect the specifics of your brief, you have learned something important before signing a larger contract. A development partner who resists doing discovery at all, or who offers to skip it in exchange for a lower price, is a development partner worth avoiding.
After discovery, the UX design phase turns the functional specification into a concrete interaction model. Wireframes are low-fidelity representations of every screen in the app, showing layout, navigation, and content structure without any visual design applied. They are the architectural drawings of your app: the equivalent of a building's floor plan before any interior design decisions are made.
Wireframes allow you to evaluate the user experience before any code is written. This is critically important because changing a user flow in a wireframe takes hours; changing it in a built app takes days or weeks. A good UX designer will test wireframes with real users, even informally, to identify confusion, missing functionality, and flows that do not match how users actually think about the task. Many UK businesses skip this user testing step and pay for it in post-launch support costs when users cannot figure out how to use the app.
The UX phase also produces clickable prototypes, typically built in Figma, that allow stakeholders to experience the interaction model before development begins. These are valuable for internal sign-off, for presenting to investors or board members, and for developer briefings. The investment in a thorough UX phase, typically ยฃ8,000 to ยฃ25,000 for a business app, consistently reduces total project cost by catching design problems before they become code problems. Our UX design service treats wireframing and prototyping as a core deliverable, not a box-ticking exercise.
Visual design applies your brand identity, colour palette, typography, iconography, and imagery to the wireframe structure. A good UI designer does not simply make things look attractive; they make the interface faster to understand, easier to use, and more trustworthy. Colour, contrast, spacing, and visual hierarchy all communicate meaning and hierarchy to users before they read a word of text.
For mobile apps, visual design must account for both iOS and Android platform conventions. iOS Human Interface Guidelines and Android Material Design each specify how certain elements should look and behave, including navigation bars, tab bars, modal sheets, and system fonts. Apps that ignore these conventions feel wrong to platform-native users even if they cannot articulate why. A skilled UI designer produces designs that honour platform conventions whilst expressing your brand.
Visual design for a business app typically costs ยฃ6,000 to ยฃ20,000 and takes three to six weeks. Consumer apps with ambitious aesthetics invest more. Internal enterprise tools can often adopt standard platform UI patterns and invest the savings in functional capability instead.
Development typically follows an agile methodology with two-week sprints. At the start of each sprint, the development team selects features from the prioritised backlog and commits to delivering them by the end of the sprint. At the end of each sprint, they demonstrate working software to the client and collect feedback. This cycle of build, demonstrate, feedback, and repeat is the most reliable way to catch problems early and ensure the finished app reflects your actual needs rather than what was written in a specification many months ago.
The technology decisions made during development have long-term consequences. The choice of framework, whether native Swift or Kotlin, React Native, or Flutter, affects performance, maintenance cost, and hiring options. The choice of backend architecture, whether to use a BaaS like Firebase, a headless API built in Node.js, Laravel, or Django, or a serverless architecture on AWS or Google Cloud, affects scalability, cost, and control. Your development partner should explain these choices in plain English and justify them against your specific requirements, not default to their preferred stack without context.
A realistic development timeline for a UK business app is three to eight months for a moderately complex application. Simple apps with one user type, no custom backend, and limited integrations can be built in eight to twelve weeks. Enterprise apps with complex workflows, multiple user roles, deep integrations, and custom backend systems take six to twelve months. Timelines shorter than these for non-trivial apps are almost always achieved by cutting corners in testing, compressing design, or assuming the spec will not change, which it will.
For UK businesses considering their first app, our mobile app development service includes sprint reviews at the end of every two-week cycle. You see working software regularly and provide feedback before the project is too far advanced to incorporate it cheaply.
Quality assurance is not an event that happens at the end of development. It is a continuous discipline that runs throughout every sprint. A dedicated QA engineer writes test cases based on the functional specification, runs them against each build, logs defects, verifies fixes, and maintains a running register of what has and has not been tested. This discipline is what separates apps that work reliably in production from those that fail unpredictably with real users and real data.
Several types of testing are required before a production app can be released with confidence. Functional testing verifies that every feature works as specified. Regression testing verifies that fixing one bug has not introduced a different bug elsewhere. Device testing verifies that the app works correctly across the range of devices your target users are likely to use, which is particularly important for Android given its device diversity. Performance testing verifies that the app remains responsive under realistic load conditions. Security testing checks for common mobile app vulnerabilities including insecure data storage, unencrypted network traffic, weak authentication, and improper session handling.
UK GDPR requirements add a specific testing obligation for apps that handle personal data: you must be able to demonstrate that appropriate technical measures protect user data. A penetration test or security audit before launch is not a legal requirement in all cases, but it is standard practice for UK apps handling financial, health, or other sensitive data. The Information Commissioner's Office expects data controllers to implement security proportionate to the risk; for most apps with user accounts, that means documented security testing.
Beta testing through TestFlight on iOS and Google Play's closed or open testing tracks on Android allows you to distribute the app to real users before public launch without going through the full App Store review process. A structured beta programme with 50 to 200 users from your target demographic identifies usability issues, performance problems, and edge cases that internal testing misses. It also builds an engaged group of early users who are invested in the app's success and willing to provide constructive feedback.
A realistic cost breakdown for a mid-complexity UK business app, cross-platform, two user types, custom backend, three integrations, full design, looks as follows. Discovery and strategy: ยฃ8,000 to ยฃ15,000 over three to four weeks. UX wireframing and prototyping: ยฃ8,000 to ยฃ18,000 over four to six weeks. Visual design: ยฃ8,000 to ยฃ18,000 over three to five weeks. Development front end and back end: ยฃ40,000 to ยฃ90,000 over twelve to twenty weeks. QA and testing: ยฃ8,000 to ยฃ18,000 included in development sprints, with dedicated pre-launch testing. App Store submission and go-live support: ยฃ2,000 to ยฃ5,000.
Total for a mid-complexity app: ยฃ74,000 to ยฃ164,000. This is a realistic range for a London agency working at professional standards. Agencies outside London typically come in 20 to 30 per cent below these figures. Offshore development teams can reduce development costs significantly but introduce coordination overhead, communication risk, and variable quality that must be factored into the overall risk assessment.
App Store fees are minor but real: ยฃ99 per year for the Apple Developer Programme, approximately ยฃ20 as a one-off for a Google Play Developer account. These are direct costs to your business, not to the development agency.
A clear, well-structured brief is the single most effective way to get high-quality proposals from development agencies and to avoid the cost of misaligned expectations. A good brief does not need to specify technical solutions. It does need to describe the problem, the users, the constraints, and the success criteria clearly enough that a competent development team can design the right solution.
Your brief should include: a description of your business and why you are building this app now; the problem the app solves and for whom; a description of the target users including their technical sophistication, context of use, and device preferences if known; the core features you believe are required as a list, not a specification; any technical constraints including integrations with existing systems, compliance requirements, and performance requirements; your budget range, since giving a range is more useful than refusing to state a budget; and your desired timeline. Include any examples of apps you admire and why, even from unrelated industries. These give designers and developers useful reference points.
Describe the outcome you want, not the technical implementation. A brief that describes users being able to book appointments without calling is more useful than one that specifies a particular integration approach. The first describes the problem; the second constrains the solution before the design conversation has happened.
The contract between a UK business and a mobile app development agency should address several key areas that are frequently overlooked or left vague until they cause disputes. Intellectual property ownership is the most important. The contract must explicitly state that all code, designs, and documentation produced become the property of the client upon payment. Some agencies include clauses that retain IP until final payment is made; others have perpetual licence clauses that give the agency ongoing rights to the code. Neither is acceptable as a default; you should own the code outright upon payment.
Source code access and escrow should be addressed. You should have access to the source code repository throughout the project, not just at the end. Hosting the repository on GitHub, GitLab, or Bitbucket under your own account with the agency as contributors is standard practice. This ensures you are never locked out of your own code.
Change management procedures should be explicit. What happens when requirements change? How are changes priced? What is the process for requesting and approving changes? Disputes about scope creep are the most common source of conflict between UK businesses and development agencies. A contract that is silent on this invites disagreement.
Payment milestones should be tied to deliverables, not time. Payments at project kick-off, completion of design, completion of development or defined development milestones, and post-launch are a sensible structure. Avoid contracts where the full payment is due before the final deliverable is accepted or where payment is front-loaded to a degree that removes the agency's incentive to complete.
Non-disclosure provisions should be bidirectional. The agency should not disclose your business plans, and you should not publicly claim a product was built by a team you did not engage. A mutual NDA signed before detailed discovery conversations is standard professional practice.
Data Processing Agreements are required under UK GDPR whenever a development agency processes personal data on your behalf, which they will during development and testing. Your development partner should be willing to sign a DPA without negotiation. A partner who is not familiar with DPA requirements is not equipped to build UK-facing apps that handle personal data. Our API integration and development work always includes a properly scoped DPA covering all data handling activities.
App Store submission is not a formality. Both Apple and Google review apps before publishing them, and first submissions have a meaningful rejection rate. Understanding the process prevents it from becoming a source of unexpected delay at the end of an otherwise well-managed project.
Apple typically takes one to three business days to review a new app submission. Common rejection reasons include: crashes during review testing, privacy manifest inaccuracies (Apple now requires all apps to declare the reason for using certain APIs), misleading screenshots or descriptions, in-app purchase compliance issues, and missing required features such as account deletion for apps with user accounts. Budget two to three submission cycles and three to four weeks from first submission to public availability in your project plan.
Google Play typically reviews new apps within a day. Google's automated scanning continues after publication, and policy violations discovered post-launch can result in removal. Both stores now require a Data Safety form on Google Play and App Privacy details on Apple's App Store that accurately describe every type of data the app collects, how it is used, and whether it is shared with third parties. Inaccurate declarations are a frequent source of post-launch store enforcement actions.
Factor four to six weeks from development completion to public availability in your launch timeline. This covers final QA, beta testing, App Store asset preparation including screenshots, preview videos, and app descriptions, review time, and a buffer for re-submissions if needed.
Unclear specification is the most common root cause. When the brief is vague, the contract is vague, and the outcome is a vague app that does not quite solve the problem it was supposed to solve. Every conversation about what the app should do is cheaper when it happens before development than during it. Invest in clarity at the start.
Scope creep without budget adjustment destroys more UK app projects than technical failure. As development progresses, stakeholders think of new features, change requirements, and add complexity. Without a formal change request process, these additions accumulate silently until the timeline and budget are blown and both sides are frustrated. A good development contract specifies the change management process explicitly.
Insufficient testing budget is the third common cause of failure. Testing is frequently the first budget line to be cut when projects run over. This is precisely backwards: cutting testing budget at the end of a project means releasing an app you do not know works reliably. Bugs discovered by users after launch cost five to ten times more to fix than bugs caught in QA.
Neglecting the post-launch phase is the fourth cause. An app that launches successfully still needs monitoring, bug fixes, OS update compatibility work, and feature development based on user feedback. Businesses that spend the entire app budget on the build and arrive at launch with no maintenance resource discover within six months that their app is degrading relative to user expectations and platform requirements.
Choosing the wrong development partner is the fifth and most expensive mistake. A partner who lacks experience with apps of similar complexity, who cannot articulate their development process clearly, or who gives you a quote without doing a discovery phase is a risk that will likely cost more in rework and delay than the apparent savings justified. The guide on how to find and vet a mobile app developer in London covers the evaluation process in detail.
A realistic timeline for a professional mobile app development project in the UK is four to nine months from initial brief to public launch. A simple app with limited functionality and no complex backend takes three to five months. A mid-complexity app with custom backend, multiple integrations, and two user types takes five to eight months. Complex enterprise apps take eight to fourteen months. These timelines include discovery, design, development, QA, and App Store submission. Projects that try to compress below these timelines almost always suffer from inadequate testing, rushed design, or specification ambiguity that causes expensive late-stage rework.
A mid-complexity business mobile app built by a London agency typically costs ยฃ60,000 to ยฃ140,000 covering all stages from discovery to launch. Simple apps with limited functionality can be delivered for ยฃ25,000 to ยฃ50,000. Complex enterprise applications cost ยฃ150,000 to ยฃ300,000 or more. These figures cover a cross-platform app for both iOS and Android from a shared codebase, with professional design, custom backend, and standard integrations. Annual maintenance after launch typically adds ยฃ15,000 to ยฃ40,000 per year to the total cost of ownership.
Under UK law, the developer who writes the code owns it by default unless the contract explicitly transfers ownership. Ensure your development contract includes a clear IP assignment clause stating that all code, designs, and documentation become your property upon payment. Also ensure you have access to the source code repository throughout the project by having the repository hosted under your own GitHub or GitLab account. Any development agency that resists these reasonable requirements should be removed from your shortlist.
A good app brief includes: your business context and the problem you are solving; a description of your target users; the core features you believe are required; technical constraints including existing systems to integrate and compliance requirements; your budget range; your desired timeline; and examples of apps you admire and why. You do not need to specify the technical implementation. Describe the outcome you need, not the technical method of achieving it. A clear, honest brief produces significantly more accurate and useful proposals than a vague one, and it demonstrates to development agencies that you are a serious, well-prepared client.
The five most common mistakes are: insufficient discovery resulting in a vague specification; scope creep without a formal change management process; cutting the testing budget when the project runs over; failing to plan and budget for post-launch maintenance; and choosing a development partner based on price rather than demonstrated experience with similar projects. Each of these mistakes is more expensive to correct after the fact than to prevent at the outset. The most important investment you can make in a mobile app project is a thorough discovery phase with a development partner who has built apps of comparable complexity.
More from the blog
Let us help
Talk to our London-based team about how we can build the AI software, automation, or bespoke development tailored to your needs.
Softomate Solutions Limited
Deen Dayal Yadav
Online
