Most mobile products do not need two native teams. They need one app that runs on iOS and Android, talks to an API, and can be updated without a rewrite every quarter. That is the work this page describes: Flutter or React Native, scoped properly, with the backend included only if you actually need us to build it.
Who this is for
- You have a web product and need a mobile client for the same users.
- You are launching a product where the phone is the main interface.
- You have an app that crashes, cannot be updated, or was built by a vendor who left.
- An agency wants the mobile build delivered white-label.
This is a poor fit for a highly specialised native feature (custom camera pipelines, heavy on-device ML) unless that slice is explicitly scoped with a specialist. We will say that on the call instead of absorbing it into a normal app quote.
What we build
- The flows in the scope: sign-in, the main job of the app, and the empty and error states users actually hit.
- Integration with your API, or a new API if you do not have one. That API is quoted on its own line.
- Push notifications when they are part of the product, not as a default add-on.
- A build you can install before it ever reaches a store, so you are not reviewing screenshots.
Design can be included. If the project needs a dedicated mobile designer, a specialist is brought in and named up front. The founder remains the person you talk to.
Process and timeline
We choose Flutter or React Native in the scoping call and do not switch mid-project without a reason you agreed to. You get installable builds of the main path first. Store listing, privacy text, and screenshots are scheduled as their own step if release is in scope, because those items slip otherwise.
A small companion app is often a few weeks after the API exists. An app that is the whole product, with offline use and payments, is longer. Starting prices are published only once you confirm the numbers you want shown; the structure of fixed, hourly, and retainer work is on pricing.
What changes the price
Offline support, in-app purchases, maps, and store submission support move the price more than the framework choice. An existing broken app can cost more to stabilise than a small new one. We will tell you which situation you are in after we see the code or the spec.
Related services
API and backend development for the server. Custom web applications if you also need a web client. Maintenance for updates after the first release.