How much does a mobile app cost in Kenya?

App quotes in Kenya swing wildly, from KES 200,000 to several million, and that spread is not all dishonesty. "An app" covers everything from a simple booking tool to a platform with payments, accounts, and a backend behind it. Here is how to read the range, work out where your project sits, and decide whether you need an app at all.

The realistic ranges

What drives the cost

• Features. Every screen and every flow is development time. Fewer, sharper features cost less and ship sooner, and they are easier to explain to a user.
• Platforms. Building separately for iOS and Android costs more than one cross-platform codebase, and it costs more again every time you update.
• Backend. An app that stores data, takes payments, or has accounts needs a server behind it, and that server is a real part of the budget rather than a footnote.
• Polish. The distance between "works" and "feels good" is genuine effort, and it is the distance users notice.

Cross-platform changes the arithmetic

For most Kenyan businesses, building cross-platform with React Native or Flutter, one codebase serving both iOS and Android, cuts build time and cost by roughly a third without a drop in quality users would notice. Native, meaning separate builds, is worth it when you lean hard on device hardware or need the smoothest possible performance.

The saving compounds after launch, and that is the part people miss. Two codebases mean every fix is done twice, tested twice, and submitted twice. Over two years of updates, the maintenance gap usually exceeds the build gap.

Built for Kenyan phones and networks

The specification that matters most here rarely appears in a brief: what the app does on a bad connection. An app that shows a spinner on one bar of signal is an app people delete. Screens should read from a local store first and reconcile with the server after, so something useful appears immediately, and writes should queue and replay when the connection returns.

The same applies to size. A large download on metered mobile data is a real barrier, and it is a decision made during the build rather than fixed afterwards. Ask what the install size will be and whether anyone is watching it.

A worked budget

Suppose you run a gym chain and want an app for bookings and membership. Compare building everything at once against shipping an MVP:

The last row is the argument. Both paths may end up in the same place, but one commits KES 900,000 to a set of guesses about what members want, and the other commits KES 320,000 and then decides what to build next using evidence. If the loyalty feature turns out to go unused, the MVP path saved you the cost of building it. If it turns out to be the thing everyone asks for, you build it next with far more confidence.

Getting into the stores

Building the app and shipping the app are two different projects, and the second one has a queue you do not control. Budget for it in both money and patience:

• Developer accounts: Apple charges annually, Google charges a one-off. Register them in the business name, not a staff member's personal account, or you will be doing an ownership transfer later.
• Review takes days rather than hours, and a rejection resets that clock. Plan a launch date with slack in it and do not book the marketing before you have an approved build.
• Common rejection causes are mundane: a missing privacy policy, a login the reviewer cannot get through, or a permission the app requests but never explains. All are avoidable.
• Every future update goes through the same queue, so an urgent fix is never as urgent as you want it to be.

If your app takes payments, read the store rules on that before you design the flow rather than after. The distinction between digital goods and physical goods changes what you are allowed to do, and finding out during review is expensive.

What to budget after launch

An app is not a one-off purchase, and this is the line most quotes leave out. iOS and Android both ship yearly updates, and each one can break something or deprecate something you rely on. An app left alone for two years usually needs real work before it will build at all, let alone pass review.

As a planning figure, set aside something in the region of 15 to 20% of the build cost per year for maintenance, and treat that as the price of keeping the thing alive rather than as an optional extra. On a KES 400,000 MVP that is roughly KES 60,000 to 80,000 a year, before any new features. If that number does not fit the business case, the app does not fit the business case, and it is much cheaper to learn that now.

Be honest about whether you need an app

This is the cheapest advice in this guide. If people would open it once or twice a year, a fast website will serve you better for a fraction of the cost, and it costs nothing to install. Apps earn their place through frequency, and through something a browser cannot do: push notifications people welcome, offline use, or a device feature you genuinely need.

• Weekly use or more: an app can make sense.
• A few times a year: build a fast, well-structured website instead.
• You mainly want to send notifications: check whether email, SMS, or WhatsApp reaches them more cheaply first.
• You want to be in the store for credibility: that is a marketing budget, not a product decision. Price it that way.

The most expensive app is the one you over-build before you know what users want. Ship the smallest version that delivers real value, get it into people's hands, and grow it from how it is used rather than from a wishlist written before launch.