Blog, Apps, 5 min read
Before you build a mobile app, decide these first
Native or cross platform, iOS or Android or both, what goes in version one, and who owns the store accounts. The decisions that shape cost and timeline.
Most app projects that go over budget do not go wrong in the code. They go wrong in the first two weeks, when a handful of decisions get made quickly, or not made at all, and then get revisited halfway through the build.
None of these decisions need technical knowledge. They need a clear view of who the app is for and what it has to do first. Here are the ones worth settling before anyone writes a line of code.
Do you need an app at all
It sounds like an odd question from a studio that builds apps, but it saves people money. A lot of ideas work just as well as a fast, mobile friendly website or a web app that people can add to their home screen. That route is quicker to build, has no app store review, and updates the moment you publish.
A native app earns its place when you need things the browser does poorly: reliable push notifications, offline use, the camera, location in the background, payments through the stores, or simply being found in the App Store and Google Play. If your idea needs one or more of those, an app makes sense. If not, start with the web and add an app later.
iOS, Android or both
Your users decide this, not your preferences. Look at who they are and where they are. In some markets and age groups iPhone is far more common. In others Android dominates. Your own analytics, if you have a website, will tell you which devices your visitors use.
If you can only launch on one, launch on the platform most of your early users have, then follow with the other. If you need both from day one, that pushes you towards a cross platform approach.
Native or cross platform
A native app is built separately for each platform, in Swift for iOS and Kotlin for Android. A cross platform app uses one codebase for both, with a framework such as React Native or Flutter.
For most business apps, cross platform is the sensible default now. You build once, the apps feel native to users, and updates ship to both stores together. Native still wins for apps that push the hardware hard, such as advanced camera work, heavy graphics or deep integration with the operating system. If you are not sure which you need, you probably need cross platform.
What goes in version one
The first version should do one job well. Write down the single most important thing a user needs to do, then list only the screens and features needed to do it. Sign up, the core action, and a way to get help. Everything else goes on a later list.
This is the hardest discipline in app projects. Every stakeholder has a feature they consider essential. But each one adds design, build, testing and review time, and you learn far more from real users than from a longer launch list. A focused version one, shipped sooner, almost always beats a bigger one shipped late.
Accounts, data and the backend
Most apps need somewhere to store users and their data. Decide early how people sign in: email, phone number, Apple, Google or a mix. If your app lets people create an account, Apple requires that they can also delete it from inside the app, so plan for that from the start.
Then decide where the data lives and who looks after it. A managed backend such as Supabase or Firebase keeps costs and setup low for most early apps. If you are handling payments, health information or other sensitive data, get advice on the rules that apply before you choose.
The store accounts and who owns them
To publish, you need an Apple Developer account and a Google Play developer account. Set them up in your company's name, not your developer's. Apps get stuck when the only person with access to the store account has left, or when the account belongs to a freelancer who is hard to reach.
Both stores review apps before they go live, and Apple's review in particular has clear rules on privacy, payments and content. Read the guidelines early, especially if you plan to sell anything inside the app, because how you take payment affects both the design and the fees you pay.
Design before build
A clickable prototype of the main screens, tested with a few real users, will catch problems that are expensive to fix later. It also gives developers a clear picture of what they are building, which makes estimates more accurate.
Design for the platforms too. iOS and Android users expect slightly different navigation patterns and controls. A good cross platform app respects both rather than forcing one style onto the other.
Plan for after launch
An app is never finished. Apple and Google release new versions of their operating systems every year, and apps need updating to keep working well and to stay in the stores. You will also want to fix bugs, respond to reviews and add the features users actually ask for.
Budget for this from the start. A small monthly allowance for maintenance and improvements is much easier to manage than a surprise rebuild after two years of neglect.
A short checklist
- One sentence that describes who the app is for and the main thing it does.
- Platforms for launch, based on where your users are.
- Native or cross platform, and why.
- A version one feature list that fits on one page.
- Sign in method, backend and any sensitive data rules.
- Developer accounts set up in the company's name.
- A plan and budget for updates after launch.
If you have answers to most of these, you are ready to talk to a developer. If you would like to talk to us, see our mobile app package, where we design, build and publish your app to the App Store and Google Play.