The cost of a mobile app for a small business depends almost entirely on what the app has to do. A focused app with a handful of screens that presents your services, takes enquiries and sends reminders sits at the lower end; an app with customer accounts, online payments, live integration with your booking or stock system and a custom backend costs considerably more. At Apptavio, apps start from £1,499 (indicative starting price), and the final price is set by the scope you agree, not by a headline number.
This guide explains what you are actually paying for, which decisions move the price the most, and how to avoid paying for features nobody uses.
What "an app" actually includes
When people compare app prices, they are often comparing very different things. A mobile app project usually has some or all of these parts:
- Design: screen layouts, navigation, branding, accessibility and the small details that make an app feel native on iPhone and Android.
- Front-end development: the app itself, which is what customers download and tap through.
- Backend: servers, databases and admin tools that store accounts, bookings, orders or loyalty points. Some apps need none; some need a lot.
- Integrations: connections to systems you already use, such as booking software, an online shop, a point-of-sale system or a CRM.
- Store publishing: preparing listings, screenshots, privacy disclosures and builds for the App Store and Google Play, and responding to review feedback.
- Maintenance: updates for new operating system versions, security fixes, dependency upgrades and small improvements.
A quote that looks cheap may simply leave out the backend, the integrations or the maintenance. Always ask which of these parts are included.
The main cost drivers
Number and complexity of screens
Every screen has to be designed, built, tested on different devices and kept working. A simple information screen is quick; a screen with forms, validation, empty states, error handling and offline behaviour takes much longer. Counting screens is a rough but useful first measure of size.
Features
Some features are cheap to add because mature, well-supported building blocks exist. Others carry real complexity:
| Feature | Typical complexity | Why |
|---|---|---|
| Service or product listings | Low | Mostly presenting content you already have |
| Contact, call and directions buttons | Low | Uses standard phone and map capabilities |
| Enquiry or quote request forms | Low to medium | Needs validation and somewhere to send the data |
| Customer accounts and login | Medium | Authentication, password reset, account deletion, privacy |
| Appointment booking | Medium to high | Availability rules, staff, cancellations, reminders |
| Loyalty stamps or points | Medium | Needs a backend to record and verify rewards |
| In-app payments | Medium to high | Payment provider integration, receipts, refunds, compliance |
| Push notifications | Medium | Permission flow, delivery service, message management |
| Integration with existing systems | Varies widely | Depends entirely on the other system's API |
Integrations with your existing systems
Integrations are the most common source of surprises. If your booking platform, shop or stock system has a documented API (a programming interface that other software can use), connecting your app to it can be straightforward. If it does not, or if API access requires a higher subscription tier, the options are more limited: we may need to build a separate backend, sync data in a simpler way or recommend a different approach. Before quoting, it is worth confirming which systems you use and what access your current plan includes.
Backend and admin tools
If your app only displays information and sends enquiries by email, it may need little or no backend. If customers create accounts, book slots, collect points or place orders, something has to store and manage that data securely, and you will usually want an admin screen to see and change it. A custom backend adds design, development, hosting and maintenance costs. Reusing an existing system through its API is often cheaper.
Authentication and accounts
Login sounds simple, but a production-quality account system includes sign-up, sign-in, password reset or passwordless email links, account deletion (which Apple requires for apps that support account creation, see the App Review Guidelines), and careful handling of personal data. If you do not need accounts for version one, leaving them out saves money.
Payments
Taking payments for physical goods or real-world services usually means integrating a payment provider such as Stripe. Selling digital content or subscriptions consumed inside the app is different: Apple and Google generally require their own in-app purchase systems for those, and they take a commission. Apple's App Store Small Business Program offers a reduced commission rate for eligible developers; check the current terms on Apple's official page before you plan around it.
Native capabilities
Using the camera, location, Bluetooth, biometric login, Apple Wallet passes or background tasks adds work, permission handling and testing. Each capability is worth it when it solves a real customer problem, and worth dropping when it does not.
Design depth
Using a well-crafted design system adapted to your brand is faster than designing every screen from scratch. Highly custom illustration, animation and unusual navigation patterns take more time.
Costs that are not development
Even a well-scoped project has costs outside the build itself:
- Apple Developer Program membership: Apple charges an annual fee to publish on the App Store. Check the current amount on the Apple Developer Program page.
- Google Play Console registration: Google charges a one-off registration fee for a developer account. Check the current amount in the Google Play Console documentation.
- Hosting and services: any backend, database, push notification service, email service or analytics tool may carry a monthly cost.
- Store commission: only if you sell digital goods or subscriptions through in-app purchase.
- Maintenance: Apple and Google release major operating system versions every year, and the libraries an app depends on change too. Apps that are not maintained gradually break or fall out of line with store requirements.
Store developer accounts should be registered in your business's name, so the app and its listing belong to you.
Illustrative project shapes
The table below describes typical project shapes rather than market prices. It is meant to help you place your idea, not to give you a quote.
| Shape | What it usually includes | What makes it cheaper or dearer |
|---|---|---|
| Focused presence app | Branded home, services or menu, opening hours, contact and directions, enquiry form | Few screens, content from your existing website, no accounts |
| Customer engagement app | The above plus accounts, loyalty, offers and push notifications | Needs a backend; notifications need opt-in flows |
| Booking or ordering app | Availability, booking or ordering flow, reminders, payment | Integration with your existing booking or ordering system is the big variable |
| Operational or portal app | Customer portal, documents, job status, approvals, staff tools | Roles, permissions, data security and integrations dominate the cost |
Apptavio's indicative starting price applies to the simplest shape. Everything else is quoted after scoping.
How cross-platform development affects cost
Building separate native apps in Swift for iPhone and Kotlin for Android means two codebases to build, test and maintain. Cross-platform frameworks such as React Native let one TypeScript codebase run on both platforms, using native interface components rather than a web page in a frame. Apptavio builds production apps with React Native, Expo and TypeScript for this reason: for most small business apps it reduces build and maintenance costs without giving up a native feel. When a feature truly needs platform-specific code, native modules can be added for that part only.
How to keep the cost under control
- Start with the problem, not the feature list. "Customers keep phoning to ask if their car is ready" leads to a smaller, clearer app than "we need an app with everything".
- Plan a minimum viable first version. Launch with the features that solve the main problem, then add more based on how customers actually use it.
- Reuse what you have. Your website content, branding and existing systems are assets. An app that connects to them is cheaper than one that replaces them.
- Check your integrations early. Ask your software providers whether they offer an API on your current plan.
- Budget for the year, not just the launch. Include store fees, hosting and maintenance in your numbers.
- See it before you commit. A clickable concept settles many scope questions that would otherwise surface halfway through development.
Seeing your app before you buy
Most cost overruns come from unclear scope: features that were assumed but never written down, or screens that turn out to need more than anyone expected. Apptavio's free app preview addresses this directly. We use your existing public website, including your services, products, opening hours and branding, to create a personalised interactive app concept that you can open in a browser on your phone or computer. A person reviews every concept before it is sent to you.
The preview is a concept, not a finished native app: features such as booking or payment are simulated. It gives you something concrete to react to, which makes the conversation about scope, and therefore price, far more precise. If you then want to go ahead, we agree the scope with you and provide a quote. There is no obligation and no payment details are needed.
Summary
A small business app does not have a single price. It has a set of cost drivers you can control: the number of screens, the features you choose, the systems it connects to, whether it needs a backend, accounts, payments and notifications, and how you plan to maintain it. Decide what problem the first version must solve, check what your existing systems allow, and get a clear, written scope before accepting any quote.
Frequently asked questions
What is the cheapest way to get a mobile app for my business?
Keep the first version small: a focused set of screens that solve one or two clear customer problems, built once with a cross-platform framework such as React Native so iPhone and Android share a single codebase. Avoid custom backends and complex integrations until you have proof that customers use the app.
Does Apptavio have a fixed price?
No. Apptavio's apps start from £1,499 (indicative starting price), but every project is quoted after we agree the scope. Screens, features, integrations, backend work, payments, notifications, native capabilities and maintenance all affect the final figure.
Are there costs after the app is launched?
Yes. Expect store account fees paid to Apple and Google, hosting for any backend, third-party service subscriptions, and maintenance to keep the app compatible with new iOS and Android versions. Budget for these from the start.
Do Apple and Google take a cut of my sales?
It depends on what you sell. Apple and Google charge commission on digital goods and subscriptions sold through in-app purchase. Physical goods and services delivered outside the app, such as a grooming appointment or a takeaway order, normally use a standard payment provider instead. Check the current store rules before you plan your pricing model.
Can I get a quote without a detailed specification?
You can get an indicative estimate from a short list of the features you need, but a reliable quote needs agreed scope. A free interactive app preview built from your website is a practical way to settle that scope before you commit.
Sources
Sources we used for factual claims in this article:
About the author
Apptavio Editorial Team
Editorial team
Articles are written and reviewed by the team at Apptavio, which designs and builds custom iPhone and Android apps for small and medium-sized businesses using React Native, Expo and TypeScript. We explain how app projects work in practice, link to official documentation for platform rules and fees, and update articles when those rules change.