Mobile App Development
An app is a product, not a project. That distinction is where most app budgets go wrong: the build is the smaller half of the commitment. Afterwards come the operating system updates that break things twice a year, the store policy changes, the backend that has to keep running, and the support requests from people who cannot log in.
Discovery and scoping, ending in a written scope and a fixed price for phase one · An honest recommendation on native, cross-platform, progressive web app or responsive website before anything is committed · Screens designed and made clickable, then tested on an actual phone before development starts · Backend and API work, usually started before the app itself
On this page
- Do you actually need a native app?
- When is a native app the wrong answer?
- What is the middle option most people have not considered?
- What do we build?
- Should you build native or cross-platform?
- How does an app get from idea to the store?
- What does an app need that a website does not?
- What drives the cost of a mobile app?
- What are the running costs of an app?
- Who owns the source code and the store accounts?
- What happens if you want to move to another developer?
- What have we built, and for whom?
Do you actually need a native app?
Often, no. A page like this one is not supposed to ask, and we are asking because a meaningful proportion of the people who come to us wanting an app would be better served by something cheaper. You probably do need one in five situations, each about what the device can do.
- It needs deep device features — the camera in a specific way, GPS running in the background, Bluetooth to hardware, sensors
- Push notifications are central to the product rather than a nice addition
- It must work properly offline for extended periods
- App Store or Play Store presence matters for discovery or credibility with your customers
- Performance demands are high — heavy graphics, real-time processing, large local data
When is a native app the wrong answer?
When the thing you are describing is really a website with a login, or software people will use at a desk. Five patterns come up repeatedly, and in every one of them the store submission, the two codebases and the annual maintenance are cost without corresponding benefit.
- The main use will be at a desk or on a tablet
- It is essentially a website with a login — which is a browser-based application, not a mobile product
- You need it working across every platform on one budget
- You will update it frequently and do not want to wait for store review
- Your users are staff, customers or partners you can simply send a link to, in which case a properly built responsive website may be the whole answer
What is the middle option most people have not considered?
A progressive web app: home screen icon, works offline, push notifications on most platforms, one codebase, no store submission, instant updates. It covers a surprising amount of what people assume needs a native build, at a fraction of the cost. We build all three, and we will tell you which one fits — including when the answer is the cheapest.
What do we build?
Eight things, of which only the first three are the app itself: iOS, Android and cross-platform builds. The rest is the server side, the admin tooling, the integrations, the store work and the progressive web app option — consistently the part clients have not budgeted for and always the part they need.
- iOS applications. Native Swift where the requirement justifies it — heavy device integration, demanding performance, platform-specific features.
- Android applications. Native Kotlin, on the same basis.
- Cross-platform applications. React Native, producing iOS and Android from one codebase. For most business applications this is the sensible choice: one build, one set of updates, substantially lower cost, and a user experience that is genuinely good rather than merely acceptable. The trade-off is that some deep platform features need native modules written alongside.
- Backends and APIs. The part clients rarely budget for and always need. An app is a window onto a server — user accounts, data storage, business logic, integrations, push notification infrastructure. This is often more than half the actual work, and it is the same discipline as any bespoke system we build.
- Admin dashboards. Somewhere for your team to manage users, content, orders and support without a developer running database queries. Needed from day one and routinely forgotten until week ten.
- Integrations. Connecting the app to what you already run — your CRM, your stock system, your accounts, your booking platform. Where the CRM itself is the problem rather than the app, a custom system built around your process is usually the better place to start.
- App store submission. Preparation, store listings, screenshots, privacy declarations, review responses, and the resubmissions that follow a rejection. Apple in particular rejects first submissions routinely, and knowing why in advance saves weeks.
- Progressive web apps. For the requirements that do not justify a store presence, an installable browser-based product with offline support and push notifications on most platforms.
Should you build native or cross-platform?
Our default recommendation is cross-platform, because most business applications do not need what native buys and every client benefits from a single codebase to maintain. We will recommend native when the requirement genuinely calls for it, and we will explain why rather than asserting it.
| Consideration | Cross-platform (React Native) | Native (Swift / Kotlin) |
|---|---|---|
| Cost | One build for both platforms | Effectively two builds |
| Speed to market | Faster | Slower |
| Ongoing cost | One codebase to maintain | Two |
| Performance | Excellent for most business apps | Better for graphics-heavy or processing-heavy work |
| Device features | Most available; some need native modules | Everything, immediately |
| New OS features | Slight lag after release | Available on day one |
| Best for | Business apps, portals, booking, commerce, internal tools | Games, AR, heavy media, deep hardware integration |
How does an app get from idea to the store?
Eight stages: discovery, design, backend, build, testing, store submission, launch and ongoing work. The backend usually starts before the app does, because the app needs something to talk to, and store submission needs a slot of its own that most plans forget to allow for.
- Discovery and scoping. Who uses it, what job it does, which platforms, what it connects to, and what the first release deliberately leaves out. Output: a written scope and a fixed price for phase one.
- Design and prototype. Screens designed and made clickable, tested on an actual phone before development starts. Interfaces that work on a desktop mock-up and fail in a hand are a common and avoidable expense.
- Backend and API. Usually starts before the app itself, because the app needs something to talk to.
- Build in two-week sprints. Installable test builds through TestFlight and Play Console internal testing at the end of each, so you use it on your own phone throughout rather than watching a screen recording.
- Testing. Real devices, not just simulators. Multiple OS versions, various screen sizes, poor network conditions, and the awkward cases — interrupted payments, expired sessions, permission denials.
- Store submission. Listings, screenshots, privacy declarations, and handling review feedback. Budget one to two weeks for this, and occasionally more with Apple.
- Launch and monitoring. Crash reporting, analytics and performance monitoring live from day one, so you find out about problems from data rather than from reviews.
- Ongoing. OS updates twice a year, store policy changes, bug fixes and new features. Planned for, not treated as a surprise.
What does an app need that a website does not?
Six things, and none of them exists on the web. A website ships when you press deploy; an app ships when a reviewer at Apple or Google agrees, onto a device you do not control, in a version the user has to choose to install. Everything below follows from that.
| Requirement | On the web | In an app store |
|---|---|---|
| Store review | You deploy when you are ready, and a fix can be live in minutes. | Every release is reviewed by Apple or Google before anyone gets it, and a first submission is routinely rejected for something procedural. Both the review and the resubmission are part of what an app actually costs to get live. |
| Signing and certificates | A TLS certificate that renews automatically and is otherwise invisible. | Signing keys, provisioning profiles and push certificates, each with an expiry date. Lose the Android upload key and you cannot update the app people already have — you publish a new one and start the installs again. |
| Forced upgrade paths | Everyone is on the current version the moment it deploys, exactly as with a browser-based tool behind a login. | Users decide when to update, so old versions stay in the wild for a long time. The backend has to keep speaking to them, or the app needs a version check that blocks the old ones. |
| Offline behaviour | A dropped connection usually means a failed page and a retry. | Phones lose signal in lifts, vans and basements. Local storage, a sync strategy and conflict rules are decisions taken at the start, and the choice between native and cross-platform partly turns on them. |
| Push permissions | A browser prompt most people decline, with email as the fallback. | A system prompt you get one attempt at. Ask at the wrong moment and the answer is no permanently, which removes the channel the app was often commissioned for in the first place. |
| Device fragmentation | A handful of browsers, tested on a laptop. | Two operating systems, several live versions of each, and screens from small phones to tablets. Testing happens on real devices, because a simulator will not show you what a slow, full, three-year-old handset does. |
What drives the cost of a mobile app?
What a mobile app costs is set by scope rather than by platform. The number of platforms; whether a backend already exists or must be built; how many integrations there are and whether those systems have usable APIs; offline requirements; the number of user types and permission rules; and how bespoke the design is.
| Scope | Typically |
|---|---|
| Focused app | Cross-platform, one clear purpose, accounts, a straightforward backend, one or two integrations. Three to five months. |
| Business app | Multiple user types, richer functionality, substantial backend, several integrations, admin dashboard. Five to eight months. |
| Complex or native dual-platform | Separate native builds, deep device integration, high performance demands, or large scale. Scoped individually. |
What are the running costs of an app?
Five, and none of them is optional: the two developer programmes, backend hosting, messaging services and maintenance. This is the section most agencies leave out of the proposal, which is how a business ends up with an app it can afford to build and cannot afford to keep.
- Apple Developer Program membership, charged annually
- Google Play Developer registration, charged once
- Backend hosting, charged on usage and growing as the app grows — the same infrastructure question that applies to a hosted product platform
- Push notification and messaging services, charged on usage
- Maintenance, budgeted at 15 to 20 per cent of the build cost per year for OS updates, store policy changes and bug fixes. This is an industry norm, not a markup, and an app that does not receive it will eventually stop working.
Who owns the source code and the store accounts?
You do, and the store accounts matter more than they sound. Source code, designs and the backend are yours on final payment, with the repository handed over. The Apple and Google accounts should be registered to your company from the start, because moving a published app between developer accounts is genuinely painful.
- The Apple Developer and Google Play accounts should be registered to your company, not ours, with you as account holder. An app published under an agency's developer account is extremely awkward to move, and it is a genuine hostage situation that catches businesses out every year. If we set them up for you, they are in your name from the start.
- Backend infrastructure sits in your accounts, so you are never locked out of your own data.
- No lock-in. Standard technologies and documented code, so any competent developer can pick it up.
- We do not reuse code written for your app in another client's project.
What happens if you want to move to another developer?
You leave with everything needed to ship the next release without us: the repository and its history, the backend and its data, the credentials, the documentation, and the store accounts with the signing keys that belong to them. Without those keys, the next developer cannot update the app your customers already have.
- The repository with its full commit history, covering the app and the backend, rather than a snapshot of the current files — the same handover terms as a bespoke system built for the business behind it.
- The database schema and a full data export — accounts, content, transactions — so the backend can be stood up elsewhere with real records in it.
- Environment variables and third-party credentials: API keys, mail and SMS providers, analytics, crash reporting and file storage, listed with what each one is for.
- The API documentation the app depends on — endpoints, authentication, versioning and webhook payloads — because an app talking to an undocumented backend is two problems rather than one.
- Deployment and build instructions for both halves: how to produce a signed release for each store, and how a backend release reaches production.
- App Store Connect and Google Play accounts in your own company name. These should be in your name from day one rather than ours — an app published under an agency's developer account is awkward to move, in the same way a hosting account left in a supplier's name is.
- The signing keys, certificates and provisioning profiles, with the passwords that unlock them. The Android upload key in particular cannot be replaced casually, and losing it means the next update never reaches existing users.
- Push notification credentials — the APNs key and the Firebase project — so notifications keep working through the handover rather than going quiet the week the accounts change.
- The domain, DNS, backend hosting and monitoring accounts, already registered to you, so moving to a new agency or an in-house team is an administrative transfer rather than a negotiation.
What have we built, and for whom?
We have built websites, e-commerce and business systems for clients including Delta Hospital & Research Center, Aama Jewellers, Himalayan Clean Energy, RM Agrotech, Fit and Fine, AOne Biz and Company Services Nepal — across healthcare, retail and jewellery, renewable energy, agriculture and professional services.
Our delivery record is currently international rather than UK-based, and we would rather say so than imply otherwise. We can show you working software and put you in a conversation with the engineers who built it. The delivered projects are there to look at.
The point
Our delivery record is currently international rather than UK-based, and we would rather say so than imply otherwise.
How We Work
Discovery and scoping
Who uses it, what job it does, which platforms, what it connects to, and what the first release deliberately leaves out. Output: a written scope and a fixed price for phase one.
Design and prototype
Screens designed and made clickable, then tested on an actual phone before development starts. Interfaces that work on a desktop mock-up and fail in a hand are a common and avoidable expense.
Backend and API
Usually starts before the app itself, because the app needs something to talk to.
Build in two-week sprints
Installable test builds through TestFlight and Play Console internal testing at the end of each, so you use it on your own phone throughout.
Explore Related Services
Aama Jewellers
A modern storefront replacing an outdated site, with a shorter checkout and social campaigns feeding it — built and handed over as one piece of work rather than two suppliers pointing at each other.
View Case StudyFrequently Asked Questions
How much does it cost to build an app in the UK?
It depends on the number of platforms, whether a backend exists or must be built, how many systems it integrates with and whether those have usable APIs, offline requirements, the number of user types and permission rules, and how bespoke the design is. Store fees, hosting and maintenance are ongoing and separate.
Should I build native or cross-platform?
Cross-platform for most business applications — one codebase, one set of updates, lower cost, and performance that is good for anything not graphics-heavy. Native when you need deep device integration, day-one access to new OS features, or high performance for games, AR or heavy media. We recommend on the requirement, not on invoice size.
Will we own the source code and the app store listings?
Yes to both. Code, designs and backend are yours on final payment, with the repository handed over. Store accounts should be registered to your company with you as account holder — ask this of every developer you speak to, because an app published under an agency's account is very difficult to move.
How long does app development take?
Three to five months for a focused cross-platform app, five to eight for a fuller business app, and longer for native dual-platform or complex builds. Add one to two weeks for store review, occasionally more with Apple. Backend complexity and integration work are the usual causes of overrun.
What are the ongoing costs after launch?
Apple and Google developer fees, backend hosting charged on usage, any third-party services, and maintenance. Budget 15 to 20 per cent of the build cost annually — iOS and Android both ship major updates every year, and apps that are not maintained break, then get removed from the stores.
Can you integrate the app with our existing systems or CRM?
Usually. Anything with an API, and frequently things without one. We check what your systems can genuinely do during scoping rather than assuming, because integration is where optimistic app estimates most often come apart. Where the system you need to connect to does not exist yet, it is the same team that would build the CRM itself.
Can you work with a limited budget or a small number of sprints?
Sometimes, and we will be straight about when we cannot. Below a certain scope a native or cross-platform app is unlikely to be worth building, because you would get something too thin to succeed. A progressive web app is often the better answer at that point, and it is a legitimate product rather than a consolation prize.
Do you publish the app for us?
Yes — store listings, screenshots, privacy declarations, the submission itself and handling review feedback, including the resubmission that follows a rejection. It is published under your own App Store Connect and Google Play accounts, so the app belongs to you from the moment it goes live rather than after a transfer.
What if the app gets rejected by Apple?
Common, and usually procedural — a privacy declaration, a login for the review team, an in-app purchase rule. We handle the resubmission as part of the launch. Knowing the rejection reasons in advance is most of what experience buys you here.
Let's Build Something That Matters.
Tell us what you're trying to achieve and we'll help you find the right solution.