Mobile product design
User journeys, screen designs and a clickable prototype made for small screens, one-handed use and interrupted sessions. You review the prototype on your own phone before engineering starts.
iOS · Android · Cross-platformMobile app development
Mobile app development
for iOS and Android, from one codebase.
We design, build and release mobile apps for startups and growing businesses. One team covers the interface, the app itself, the backend it talks to and the App Store and Google Play submission. We build cross-platform with React Native and Capacitor, and we say so plainly when a product needs something else.
What a mobile project coversThe app,
The app,
and everything it depends on.
An app in the store is the visible part. Behind it sit a backend, an admin tool, push and analytics services, signing keys and two store listings. We scope and deliver all of it as one project so nothing is left for you to stitch together.
iOS and Android app
One TypeScript codebase for both platforms, with authentication, push notifications, in-app purchases or subscriptions, offline storage and device features such as camera and location, as the product requires.
Backend and admin panel
The API, database and web admin area the app needs to manage users and content. Existing backend APIs can be integrated instead, or a new backend can be scoped alongside the app.
Store release and handover
Release builds, testing on real devices, store assets, privacy declarations and technical submission. Store approval remains subject to each platform’s review. Handover includes build instructions and release documentation.
Who this is for
Teams whose product belongs on a phone.
Not every product needs an app. A mobile build earns its cost when the product relies on something a browser does poorly: push notifications, the camera, location, offline use, store payments, or simply being one tap away on the home screen several times a day. If that describes your product, the typical situations we work in are:
- Startups building a first app, often as an MVP, that need both stores covered without paying for two separate native teams.
- Businesses with a working web product whose customers now expect a mobile companion: booking, ordering, account management, field work.
- Owners of an existing app that has fallen behind on OS updates, was left unfinished by a previous developer, or needs a new feature set. We can review the codebase and continue from it where that is cheaper than a rebuild.
Kinds of apps we build
- Consumer apps with accounts, feeds, favourites, notifications and subscriptions
- Booking, ordering and on-demand apps with a customer side and a provider side
- Data and tracking apps: live prices, portfolios, alerts, charts
- Companion apps for a SaaS product or an internal system
- AI-assisted apps built on hosted language models, such as assistants and companions
- Casual games, which we cover on the game development page
If a responsive web app would test the same idea for less, we will tell you. That option is described on our web application development page.
The processFour stages,
Four stages,
each with a reviewable result.
The ranges below are planning figures for a focused first release. Your scope document carries the actual dates.
How we work in detail ↗Discovery · 1–2 weeks
Users, core journeys, platforms, device features and store constraints such as payment rules. Output: a prioritised feature list, written scope with acceptance criteria, technical approach, fixed quote and timeline.
Design · 2–3 weeks
Flows and screens for the core journey, reviewed as a prototype on a real phone. Platform conventions for navigation, gestures and permissions prompts are settled here, not during the build.
Build · 6–14 weeks
App and backend developed in short iterations. You install test builds through TestFlight and Google Play internal testing from early in the project, with a demo at each milestone.
Testing and store release · 1–3 weeks
Testing across a defined set of devices and OS versions, store listings, privacy declarations, submission and any reviewer follow-up. Then handover of code, accounts and documentation.
Technology approach
Cross-platform by default. Honest about the exceptions.
We build mobile apps with two cross-platform approaches and choose between them after looking at the device capabilities, performance requirements and roadmap of the product.
| Layer | Typical choice | When and why |
|---|---|---|
| App, native UI | React Native with Expo, TypeScript | Default for most products. Real native interface components, large ecosystem, one codebase for both stores |
| App, web-based UI | Capacitor around a web front end | When a web app already exists, when the interface is content or canvas based, or when budget is tight. Both of BBR’s own published apps use it |
| Native modules | Small Swift or Kotlin pieces inside the cross-platform app | For a device feature that no maintained library covers |
| Backend | Node.js, PostgreSQL, or Firebase / Supabase | Managed services where they save weeks; a custom API where the logic is yours |
| Payments | App Store and Google Play billing; Stripe for physical goods and services | The stores require their own billing for most digital goods |
| Push, analytics, crash reporting | Platform push services, product analytics and a crash reporter | Set up before launch so the first week of real usage is visible |
| Admin panel | React / Next.js web app | Manage users, content and support without a developer |
What we do not offer. Fully native builds in Swift and Kotlin, and Flutter. If your app is dominated by platform-specific work, such as real-time video processing, demanding 3D, complex Bluetooth devices, or a watch or widget-first experience, a native team will serve you better. We compare the options in native vs cross-platform and Flutter vs React Native.
Pricing factors
What moves the cost of an app.
The screen count is a poor predictor of cost. These are better ones:
- Whether the app needs its own backend. An app that reads public data and stores preferences on the device is a fraction of the work of one with accounts, user content and an admin panel.
- User roles. A customer app and a courier app are two apps sharing a backend, even inside a single codebase.
- Payments. Store subscriptions involve receipt validation, renewal and cancellation states, restore flows and review rules. Marketplace payouts add more.
- Offline and sync. Letting users work without a connection, then merging their changes, is one of the most expensive requirements to add late.
- Real-time features. Chat, live location and live data need different infrastructure from request-and-response screens.
- Device features. Background location, Bluetooth, camera processing and health data each bring permissions, edge cases and review scrutiny.
- Design ambition. Platform-standard components are cheap. Custom animation and illustration are not.
- Device and OS coverage. Supporting older OS versions and tablets increases testing effort.
We quote a fixed price against a written scope, with payments tied to milestones, and we price any change before doing it. For effort tables and three worked examples, read how much it costs to build a mobile app. Budget separately for the years after launch; app maintenance is a real line item.
Common mistakes
Where app projects go wrong.
Building an app when a website would do
Apps cost more to build, release and maintain than web apps. If the product does not need push, device hardware, offline use or store distribution, test it on the web first and add the app when users ask for it.
Letting the developer own the store accounts
If the app is published under an agency’s developer account, moving it later requires their cooperation. Register the Apple and Google accounts in your company’s name from the start. Account verification can take days or weeks, so begin early.
Discovering store rules at submission
Both stores have rules on payments, account deletion, privacy disclosures, user-generated content and sign-in options. Designing around them in week one is cheap. Redesigning a payment flow after a rejection is not.
Testing only on the newest phone
Your users have small screens, old Android versions, low storage and bad connections. A defined device and OS matrix in the scope turns “it works on my phone” into something that can be verified.
No analytics or crash reporting at launch
Without them you cannot tell whether users finish onboarding or whether the app crashes on a particular device. Both are a day or two of work and should be in the first release.
Treating launch as the end
Operating systems change every year and the stores set deadlines for keeping up. An app with no maintenance plan degrades, then gets flagged by the store. Plan the budget before launch, not after the first warning email.
FitWhen BBR is the right team,
Good fit Not a fit
When BBR is the right team,
and when it is not.
We are a small independent studio with a specific way of building apps. It suits many products and is the wrong choice for some.
We are likely a strong match if
- You want iOS and Android from one codebase, with one team responsible for app, backend and release
- The app is built from accounts, content, forms, lists, maps, payments, notifications and similar parts
- You prefer a fixed scope and price with milestone payments
- You want the store accounts, code and infrastructure in your name
- You are comfortable working remotely in English, with written updates and scheduled calls
We will probably point you elsewhere if
- You need a fully native Swift or Kotlin build, or a Flutter team
- The core of the app is heavy on-device processing: AR, real-time video, demanding 3D
- You need an on-site team or a large group of engineers immediately
- The app is a regulated medical device or similar safety-critical software
- You want equity-only or deferred-payment development
Why outsource app development
An app needs five skills. A first hire has one or two.
A released app takes mobile engineering, backend engineering, interface design, testing and release management. Hiring for all of them before the product has users is slow and expensive, and a single mobile developer working alone is left to improvise the rest. A studio provides the full set for the length of the project, then hands over a codebase that an in-house hire can continue.
The trade-offs are real, and we describe them in how outsourcing app development works in practice and in the comparison of agencies and freelancers. If you are comparing vendors, our checklist for choosing a mobile app development company applies to us as much as anyone.
BBR publishes its own apps on Google Play under the developer name BBR Labs, so the release process described here is one we run for ourselves. Live Gold & Silver Prices is a Capacitor app with live market data, portfolio tracking and price alarms delivered as local notifications. Grow.io is an arcade game with AI-controlled opponents, ads and in-app purchases. The case studies explain the engineering decisions behind each.
QuestionsFrequently asked
Frequently asked
questions.
Do you build for both iOS and Android?
Yes. Our default is a single cross-platform codebase, built with React Native (Expo) or Capacitor, that ships to both stores. Supported devices and minimum operating-system versions are written into the scope so there is no ambiguity about what gets tested.
Do you build fully native apps in Swift or Kotlin?
No, and we would rather be clear about that. We write native modules where a cross-platform app needs them, but we do not offer full Swift or Kotlin builds. If your product depends on heavy platform-specific work, such as advanced camera processing, complex Bluetooth peripherals or an Apple Watch-first experience, a native team is the better choice. Our guide to native vs cross-platform development explains where the line sits.
How much does it cost to build a mobile app?
Scope decides it: the number of user roles, whether a backend and admin panel are needed, payments, real-time features and offline behaviour. We quote a fixed price against a written scope after a short discovery. To form your own estimate first, see how much it costs to build a mobile app.
How long does app development take?
A focused first release usually needs three to five months from kickoff to store approval, including design and testing. Simple utility apps can be quicker; multi-role products with payments and real-time features take longer. The phases are broken down in our app timeline guide.
Who owns the App Store and Google Play accounts?
You do. The developer accounts are registered in your company’s name and you invite us as a team member with the access needed to upload builds. The app listing, reviews, revenue and signing keys stay with you whatever happens to the working relationship.
Can you guarantee the app will be approved by Apple and Google?
Nobody can. Approval is each platform’s decision. What we do is build against the published review guidelines, prepare the privacy declarations and store assets, handle the submission, and respond to reviewer feedback if a build is rejected. Most rejections are resolved with a small change and a resubmission.
Do you maintain apps after launch?
Yes, as a separately scoped monthly arrangement. Apps need regular attention because iOS, Android and the store policies change every year. Our article on app maintenance cost explains what that work consists of and how to budget for it.
Your next movePlanning an app?
Planning an app?
Let’s scope the first release.
Tell us what the app does, who uses it and which platforms you need. We reply with questions, a suggested first-release scope and a realistic range.
Discuss your app ↗