Why platform isn't the main cost driver anymore

A few years ago, 'do you need iOS and Android' was the first cost question. With mature cross-platform frameworks, it's no longer the biggest lever — one codebase reaching both stores is standard practice now for the majority of business apps. The bigger cost questions are: how many unique screens does the app have, how much of the backend has to be built from scratch, how many third-party services does it talk to, and how polished does the UI need to be. Two apps with an identical screen count can differ in cost by 3x depending on those four factors.

Tier 1: Simple single-purpose app — £8,000 to £20,000

This tier covers apps built around one clear job: a single-location booking app, a loyalty/rewards card app, a content or catalogue browser, a simple internal tool for field staff. Typically 6-12 screens, one primary user role, light or no backend beyond a database and a handful of API endpoints.

  • ◆Screen count: usually under 12, with most following standard UI patterns
  • ◆Backend: minimal — a database, basic auth, a handful of REST endpoints
  • ◆Integrations: at most one or two (e.g. push notifications, a single payment provider)
  • ◆Design: functional and on-brand, not a bespoke design system

Tier 2: Mid-complexity app with backend, auth, and payments — £20,000 to £60,000

This is where most funded startups and serious SMB projects land. Think a marketplace app, a subscription service, a service-booking platform with multiple user types (customer and provider), or a companion app to an existing web product. You're building real account systems, handling payments properly, and likely maintaining an admin dashboard alongside the app itself.

  • ◆Screen count: 20-40 screens, several with custom logic (search/filter, scheduling, checkout flows)
  • ◆Backend: a proper API layer, role-based auth, and a data model that will need to evolve post-launch
  • ◆Integrations: payments (Stripe or similar), transactional email/SMS, possibly a calendar or mapping API
  • ◆Design: a defined design system so the app scales cleanly as screens are added

Stat

In our experience scoping mid-tier apps, backend and integration work — not the UI — typically accounts for 50-60% of the build hours. Clients consistently underestimate this because the UI is what they can see in a mockup.

Tier 3: Complex, real-time, or heavily integrated app — £60,000+

Apps with real-time features (live chat, live location tracking, live inventory), multiple integrated third-party systems (accounting software, CRMs, IoT devices, multiple payment processors), or genuinely novel UX that can't be assembled from standard component patterns. This tier also covers apps that need to support offline sync, complex permission structures, or multi-tenant architecture from day one.

  • ◆Screen count: 40+ screens, with a large proportion requiring custom state management
  • ◆Backend: custom architecture, potentially including websockets, queues, or background job processing
  • ◆Integrations: three or more external systems, each with its own auth, rate limits, and failure modes to design around
  • ◆Design: fully bespoke, often requiring UX research and iteration before build starts

The costs that show up after launch

Every tier above is the build cost. Budget separately for Apple Developer Program (£79/year) and Google Play Console (£25 one-time) fees, ongoing hosting and backend infrastructure, and app maintenance — OS updates alone force some code changes roughly once a year, and skipping them risks your app breaking on new devices. A reasonable rule of thumb is to budget 15-20% of the original build cost annually for maintenance on an app that isn't actively being fed new features.

The single biggest cost lever within any of these tiers is whether you build native or cross-platform — we break that decision down fully in Native vs Cross-Platform App Development. And if you're weighing an app against a web-based alternative first, our guide to website costs in 2026 covers the equivalent tiers for web builds.

If the app is actually the MVP for a wider SaaS product, read our piece on what to know before commissioning a SaaS MVP before you brief anyone — scoping mistakes at this stage are the single biggest cause of budget overrun we see. We go through this exercise properly during scoping calls, screen by screen, before any number gets quoted.

What actually drives cost within each tier

Number of unique screens

Not total screens — unique ones. A settings screen that's a list of toggles is a solved pattern any developer builds in a few hours. A scheduling screen with custom availability logic, timezone handling, and conflict detection might take a week on its own. When we scope a project, we categorize every screen as 'standard pattern' or 'custom logic,' because that split predicts the estimate far better than a raw screen count does.

Backend and data model complexity

An app with one user role and a flat data model (a simple content app, say) needs a fraction of the backend work of an app with multiple user roles, permissions, and relational data that changes shape as features are added. Multi-sided marketplaces — where customers, providers, and admins all need different views of overlapping data — are a common example of where backend complexity quietly dominates the budget even when the UI looks modest.

Third-party integrations

Each integration looks small in a spec document and rarely is in practice. Payment processing needs to handle failed payments, refunds, and webhooks, not just the happy path. Mapping APIs have usage-based pricing that needs monitoring. A calendar sync needs to handle a user revoking access mid-session. Budget roughly a week of engineering time per non-trivial integration, even for ones that have a well-documented SDK.

Design complexity and design system maturity

A functional UI using a component library gets you to launch fast. A fully bespoke design — custom animations, unusual navigation patterns, a distinctive visual identity — takes considerably longer to design and to implement faithfully, and it's harder to keep consistent as new screens get added post-launch. Neither choice is wrong; it depends on whether visual differentiation is core to your product's value or a nice-to-have.

Tip

Ask any agency quoting your app to break the estimate down by screen and integration, not just present a single total. If they can't, they haven't actually scoped it yet — they've guessed at a familiar-sounding number.

A worked example

Say you're building a service-marketplace app: customers book appointments, providers manage their calendar, and an admin views bookings across the platform. That's three user roles (tier 2 territory already), a scheduling engine with conflict detection (custom logic, not a standard pattern), Stripe for payments with provider payouts (a genuinely non-trivial integration, since split payments add complexity beyond basic checkout), and push notifications for booking confirmations. Realistically that's a £35,000-£50,000 build — solidly mid-tier, driven almost entirely by the scheduling logic and the payout structure, not by having three screens instead of two.