Which factors move the cost most?
- Features and screens — Every screen, form and rule must be designed, built and tested. This is usually the biggest factor.
- Platforms — iOS only, Android only, or both — and whether one shared codebase is suitable.
- Backend — Accounts, databases, admin panels, notifications and file storage behind the app.
- Integrations — Payments, maps, your ERP or CRM, third-party APIs — each adds build and test time.
- Design depth — Standard components are quicker; custom interfaces and motion take longer.
- Security and data — Logins, roles, personal or payment data, and the rules that apply to them.
Why do similar-looking apps cost such different amounts?
Two apps can look alike on screen and be very different underneath. A booking app that shows a static list of times is simple. One that checks live availability across locations, takes deposits, syncs with your calendar and sends reminders is several systems working together. What you can’t see — rules, data and connections — is where the effort goes.
- Offline use means storing and syncing data on the device.
- Real-time features such as chat or live tracking need extra backend work.
- User roles — customers, staff, admins — multiply the screens and permissions.
What costs continue after the app is live?
An app is never finished in the way a brochure is. Budget for:
- Updates when Apple and Google release new operating system versions.
- Hosting and monitoring for the backend.
- Developer account fees to Apple and Google. We publish apps under your own Apple Developer and Google Play accounts, so you own the listing.
- Bug fixes and small improvements based on real user feedback.
How can you keep the cost under control?
- Define the core job — One sentence: what must a user be able to do?
- Cut to a first version — Launch the smallest version that does that job well.
- Pick platforms on data — Check which phones your customers actually use.
- Reuse what exists — Your website, ERP or existing APIs can power the backend.
- Agree scope in writing — A signed feature list stops quiet scope growth.
What should you prepare before asking for a quote?
- Who the users are and what they need to do.
- A list of features, marked “must have” and “later”.
- Systems the app must connect to.
- Examples of apps you like, and why.
- Who will answer questions during the build.
What work happens that you don’t see on screen?
Beyond the screens themselves, a professional app build includes work that is easy to forget when comparing quotes:
- Testing on a range of real phones and screen sizes, old and new.
- Store submission — screenshots, descriptions, privacy details and responding to review feedback from Apple and Google.
- Analytics and crash reporting so problems are found before users complain.
- Accessibility — readable text sizes, contrast and screen-reader support.
- Documentation and handover so another team could maintain the app if needed.
When two quotes look very different, ask each supplier which of these are included.
Questions we get asked
Why won’t agencies give a price without details?
Because the feature list decides the cost. A fixed price without a written scope either hides a large buffer or leads to change requests later.
Is building for both iOS and Android twice the cost?
Not always. A cross-platform approach can share much of the code, though some work is still needed per platform.
Who owns the app once it’s built?
You should. We publish under your own Apple Developer and Google Play accounts and hand over the code.
Can we start with a web app instead?
Sometimes. If users don’t need phone features such as offline use or push notifications, a web app can be a sensible first step.
Something else on your mind? Ask us directly →
