Skip to content

Your first app: what to build first, and what to leave out

The first version of an app has one job: to show whether people use it the way you expect. What belongs in it, what can wait, and what Apple and Google require anyway.

Apps5 min readSoventia Ltd

The first version of an app has one job: to find out whether people use it the way you expect. Everything in it should serve that. Most first versions are too big, because every feature someone asks for feels essential before launch. After launch, the data usually shows which ones were.

One journey, end to end

Pick the single thing the app promises, and build the whole path to it: opening the app, doing the task, getting the result. Make that path complete and pleasant. A first version that does one thing well tells you far more than one that does six things halfway, because when people stop using it, you know why.

Write the journey down in one sentence before anything is designed. "A technician logs a finished job with photos, and the office sees it within a minute." If a feature does not help that sentence, it waits.

What to build now, and what can wait

  • The one journey that proves the idea

    From opening the app to the result it promises. Complete, and good enough that people would use it again.

  • Sign-in, only if the journey needs it

    If the app has to know who someone is, add it. Many first versions do not need accounts at all.

  • Error reporting

    You want to know the app broke before a user tells you.

  • Basic usage analytics

    Enough to see whether people finish the journey, and where they stop.

Our default split for a first version. Every app is different, but the third tab is not up for debate.

Leaving something out of version one is not saying no to it. It is saying "not until we know". Keep a list. After a few weeks of real use, half of it usually turns out not to matter, and one thing nobody listed turns out to matter a lot.

Web app, cross-platform or native

A web app runs in the browser, needs no store, and updates the moment you deploy. It is the fastest way to test an idea, and the right answer for many internal tools. Its limits are access to some device features and the lack of a store listing.

A cross-platform app is written once and runs on both iOS and Android, with frameworks such as React Native or Flutter. For most business apps it is the sensible middle: one codebase, real store apps, access to the camera, location and notifications.

A native app is written separately for each platform, in Swift for iOS and Kotlin for Android. It makes sense when the app depends heavily on the device, on top performance, or on the newest platform features.

One thing to know before choosing the store route: Apple's review guidelines say an app should offer more than a repackaged website, and if it is not particularly useful, unique or "app-like", it does not belong on the App Store. If your app is mostly content, a well-built web app may serve you better.

What the stores require

Apple App StoreGoogle Play
Privacy policyLinked in App Store Connect and inside the appLinked in Play Console and inside the app, even if no personal data is collected
Data disclosuresPrivacy details, including third-party codeThe Data safety section, including SDKs
Account deletionIn the app, if users can create accountsIn the app, plus a web link to request deletion
Build toolsXcode 26 and the iOS 26 SDK, from 28 April 2026Target Android 16 (API level 36), from 31 August 2026
Before the first releaseApp ReviewFor personal accounts created after 13 November 2023: a closed test with at least 12 testers for 14 days

Two of these catch teams out. Account deletion has to be designed in, because it touches the data model and every system the account connects to. And the Google Play testing rule adds at least two weeks for a personal developer account. Publishing under a company account avoids it, and it is where a company's app belongs anyway.

Sources

  1. App Review Guidelines (2.1, 4.2, 4.8, 5.1.1) Apple Developer
  2. App privacy details on the App Store Apple Developer
  3. Upcoming requirements Apple Developer
  4. User Data policy Play Console Help
  5. Understanding Google Play's app account deletion requirements Play Console Help
  6. Target API level requirements for Google Play apps Play Console Help
  7. App testing requirements for new personal developer accounts Play Console Help

Start with a 30-minute call.

Bring the idea as it is. We ask questions, tell you how we see it, and if we are not the right fit, we say so and point you to someone who is.