Getting installed is the easy part. Nine in ten are gone within the month.

Mobile app development South Africa businesses can actually sustain: built around the first session rather than the feature list, on the platform your users are genuinely on, and scoped so the second year does not cost more than the first.

Deep navy strelitzia stems fanned from one base on white, a single coral bloom open

Getting installed is not the same as getting used.

The problem is never the download

Every app project is planned around the launch. The store listing, the announcement, the install number in the first week. That number is achievable and it is close to meaningless, because the industry-wide pattern is brutally consistent: the overwhelming majority of people who install an app have stopped using it within a month, on both platforms, in almost every category.

They do not leave because the app was badly made. They leave because the first session did not deliver anything worth returning for. An app competes with a home screen full of things that already earn their place, and it gets roughly one attempt to prove it belongs there. Everything a user does not reach in that first session may as well not have been built.

This is what makes app scope so dangerous. A feature list is a comfortable thing to agree on, and every item on it feels reasonable. But scope is what pushes the first useful moment further from the install, and it is what makes the app expensive to keep alive - two operating systems that update annually, and a version of your product that has to be resubmitted every time anything changes.

So the first question is always whether you need a native app at all. A great deal of what businesses ask for is better served by a web app that opens instantly, is found in search, updates without a store review, and can still sit on a home screen. Native earns its cost when you genuinely need the hardware, work offline, or live somewhere a store listing is how you are found. That is a real decision with a right answer, and it is worth taking seriously before anybody writes code.

<6%

Of installed users are still there on day thirty, across both major platforms. The launch number is not the number that matters.

2x

The platforms you maintain forever the moment you go native on both. The build is quoted once; the upkeep arrives every year.

1

The number of sessions you get to prove the thing is worth keeping. Everything a user does not reach in it was built for nobody.

The discipline

Four questions, in order, before an app is worth building

The first two are commercial and are usually skipped because they are uncomfortable. The last two are the build. A project that starts at stage three is how businesses end up maintaining software nobody opens.

  1. Needed

    An app is genuinely the answer

    • What it does that a website cannot
    • Hardware, offline or notifications
    • How people would find it
    • What it replaces

    This holds it up

  2. Reached

    The first session pays off

    • The one thing it must do immediately
    • Everything removed from the path to it
    • No sign-up before value
    • Something worth coming back for

    This holds it up

  3. Built

    It works on real devices

    • One codebase where possible
    • Tested on mid-range Android
    • Sensible about data and battery
    • Offline where it matters

    They see this

  4. Kept

    It survives after launch

    • Store submissions and updates
    • Crash and error reporting
    • What people do in the first week
    • A route to the next version

    They see this

Stage one is the only stage where we might talk you out of the project. We would rather do that than build something you pay to maintain for three years and quietly stop mentioning.

What arrives

Everything on this list is yours at the end of it

Not a summary of what we will think about. The actual files, documents and decisions that land on your desk, stage by stage, and every one of them is yours to take anywhere afterwards.

  1. 01

    Needed

    • What it does that a website cannot
    • Hardware, offline or notifications
    • How people would find it
    • What it replaces

    An honest recommendation, including the one that costs us the work: that a web app or an improvement to your existing site would do this better and cheaper.

    You walk away with

    • A written recommendation on web versus native, with the reasoning shown
    • The one thing the app must do, agreed before anything is scoped
    • An honest cost of ownership, including what the upkeep will run per year
  2. 02

    Reached

    • The one thing it must do immediately
    • Everything removed from the path to it
    • No sign-up before value
    • Something worth coming back for

    A defined first-session outcome, with the build scoped around reaching it rather than around a feature list - which is usually a shorter and cheaper project than the one that was requested.

    You walk away with

    • The first-session outcome defined, and the build scoped around reaching it
    • Screens and flows prototyped and reviewed before anything is built
    • Sign-up reduced to what is genuinely required to get started
  3. 03

    Built

    • One codebase where possible
    • Tested on mid-range Android
    • Sensible about data and battery
    • Offline where it matters

    Software tested on the handsets your users actually carry, not on the newest device in the office - which in this market is the difference between a working app and a demo.

    You walk away with

    • One codebase across platforms wherever the job allows it
    • Tested on mid-range Android, not only on the newest phone in the room
    • Offline behaviour handled wherever it actually matters
    • Code in a repository in your name, with the credentials handed over
  4. 04

    Kept

    • Store submissions and updates
    • Crash and error reporting
    • What people do in the first week
    • A route to the next version

    Analytics on the first session from day one, crash reporting wired in, and a maintenance plan quoted before launch rather than discovered afterwards.

    You walk away with

    • Store submission handled, including the parts that get rejected the first time
    • Crash reporting and first-session analytics live from day one
    • A maintenance plan quoted before you commit, not discovered afterwards
    • Documentation and a handover to your own team whenever you want it

Measurement

How you will know it is working

Installs are the vanity number in mobile app development South Africa. These are the ones that say whether the thing worked.

What we report on

  • How many new users reach the first useful moment, and how long it takes them
  • Day-one, day-seven and day-thirty retention, tracked from launch
  • Crash-free session rate on real devices
  • The task the app exists for - bookings taken, orders placed, hours saved
  • Cost of maintenance against what the app returns, reviewed annually

Get web and mobile apps scoped for your business

Tell us what is happening now and you get a written scope with a price on it, from the person who would do the work.

If we think this is not actually your problem, we will say so on the call rather than after the invoice. It costs us the job often enough to be worth saying out loud.