Version one of a mid-size app is usually 8 to 16 weeks including design, build and testing. Apple review alone can take a day to a week, and we put that in the schedule rather than springing it on you.
T
R
I
P
L
E
Mobile applications
We build iOS and Android apps that actually reach the stores. The hard part of a mobile app is not the first screen — it is everything after it: Apple and Google review, privacy policy and account deletion, push notifications, and shipping updates without breaking older users' versions.
We always start with one question: do you actually need an app? Many of the ideas that reach us are better served by a fast, responsive website than by something a user has to download and keep updated. If that is your case we will say so, because an app nobody installs is a total loss.
And when an app is the right answer — repeat use, notifications, offline work, camera or location — we build one codebase that runs on both systems and handle publishing to both stores under your own name.
What you get
One app, both platforms
A single codebase running on iOS and Android at native performance, respecting each platform's navigation and gestures rather than forcing one look onto both.
Publishing to both stores
We set up App Store Connect and Google Play Console, write the listing and screenshots, and handle review feedback until approval.
Every store requirement
A published privacy policy, an account-and-data deletion page, and a data-collection disclosure. Missing any of these is a common rejection, so we prepare them before the first upload, not after.
An admin panel
Manage content, users and orders and send notifications from your browser, without shipping a new build every time the data changes.
Targeted notifications
Push notifications to everyone or to a defined segment, wired into the app's own logic rather than only sent by hand.
Secure sign-in
Email or phone sign-in with verification, or Apple and Google sign-in. Apple requires Sign in with Apple if you offer any other social login.
Usage measurement
The app ships connected to analytics showing which screens get used, where users drop off, and how many come back after a week. Without it you are developing on guesswork.
Accounts in your name
The developer accounts on both stores are registered to your company and the source code is yours. We do not host your app under our account.
How we work
Scoping
We separate what must be in version one from what can wait. A small first version launched in two months beats a comprehensive one still in development a year later.
Mapping the flows
We map the user's path screen by screen before any design: from first launch to completing the core task. This is where the forgotten screens surface — error states and empty lists.
Design
A full design for every screen in each of its states, plus an interactive prototype you try on your own phone before a line of code is written.
Building in increments
We ship a test build every two weeks through TestFlight and Google Play internal testing, so you use the progress rather than read a report about it.
Testing on real devices
We test on physical devices across sizes and OS versions, and check how the app behaves on a weak or dropped connection, and what it does to the battery.
Publishing and follow-up
We submit the app and see it through review to approval, then watch the crash reports for a month and fix what appears at no extra cost.
What we build with
- Cross-platform apps: Flutter and React Native
- Backend: Laravel or Node.js with MySQL or PostgreSQL
- Notifications, analytics and crash reporting: Firebase
- Test distribution: TestFlight for Apple and the internal track on Google Play
What drives the cost
An app is costed by its number of screens and the business logic behind them, not by the idea itself. The main factors:
- Screens and their states One screen is not one screen: it has a loading state, an empty state, an error state and a success state. That is why estimating by screen count alone misleads.
- User roles An app with one kind of user is far simpler than one with a customer, a provider and an administrator, because each role needs its own permissions, screens and flows.
- In-app payments Connecting a local payment gateway is a different job from in-store subscriptions, and the latter carry Apple and Google commission and stricter review rules.
- Offline capability Storing data locally and syncing it when the connection returns adds real complexity, and not every app needs it.
- The backend If you have an existing system we connect to it. If not, we build the backend and admin panel from scratch, and that is a separate line.
- Maintenance after launch Apple and Google ship new OS versions yearly and periodically require an updated build target. An unmaintained app eventually gets removed from the store.
After a free scoping session you get a written estimate per phase, with a clear line between version one and what can wait.
Common questions
- How long does a mobile app take?
- Do I need an app or is a website enough?An app earns its cost if users will open it repeatedly, or if you need notifications, camera, location or offline work. If the use is seasonal or one-off, a fast responsive website is better, cheaper and easier to reach.
- Does it run on both iOS and Android?Yes. We build one codebase for both, which saves roughly 40 percent against building two separate apps. For the rare cases needing very heavy graphics performance we will discuss going fully native with you.
- What if Apple rejects the app?Rejection is a normal part of the process, not a disaster. The common causes are well known: an incomplete privacy policy, a missing account-deletion page, or a listing that does not match the app. We prepare these in advance and handle the review response and resubmission within the agreement at no extra charge.
- Who owns the developer account?You do. We register App Store Connect and Google Play Console to your company and give you owner access. That protects you if you ever change development teams.
- Does the app need maintenance?Yes, and it is a fact many people leave out at the point of sale. Both stores periodically require an updated build target, and each new OS release can break something. We recommend an annual maintenance plan and quote it up front, not after launch.
Services that pair with this
Related work
Ready to start?
Book a free 30-minute consultation. We listen, and we tell you honestly whether this is the service you actually need.
Book a free consultation
Practical notes on building and marketing, once a month. No spam.