How much does a mobile app cost in Kenya?

App quotes in Kenya range widely, from KES 200,000 to several million, and the spread mostly reflects genuine differences in scope. "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

These are planning figures for a first budget, and they exclude store developer accounts, backend hosting, and maintenance, all of which are covered further down.

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

A cross-platform codebase using React Native or Flutter can share a significant portion of the implementation between iOS and Android. How much that changes total project cost depends on platform-specific features, design work, native integrations, testing requirements, and the team building it, so there is no universal percentage. Native development, meaning separate Swift and Kotlin builds, is preferred where the product depends heavily on device hardware, platform-specific interface behaviour, or demanding performance requirements.

The difference continues after launch rather than ending at it. Two codebases mean each fix is implemented twice, tested twice, and submitted twice, so the gap widens with every update cycle. That is worth weighing alongside the build estimate, particularly for a product you expect to change often.

Built for Kenyan phones and networks

The specification that most often goes unwritten is what the app does on a poor connection. If the product is expected to operate on unreliable connections, connectivity behaviour belongs in the specification: which screens read from a local store first and reconcile with the server afterwards, which actions queue and replay when the connection returns, and what the user sees for operations that genuinely require a connection.

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

An illustrative project example, not a quotation. Suppose you run a gym chain and want an app for bookings and membership. Compare building everything at once against releasing a focused first version:

The difference is in when the money is committed. Both paths may end in the same place, but one commits KES 900,000 against a set of assumptions about what members want, and the other commits KES 320,000 and then decides what to build next against usage. If the loyalty feature goes unused, the second path avoided the cost of building it. If it turns out to be the most requested feature, it gets built next with more confidence and no time lost.

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.

Ongoing cost depends on backend infrastructure, operating-system changes, third-party services, monitoring, support, security updates, and the rate of new feature development, so it should be budgeted separately from the initial build rather than treated as an extra. As a planning heuristic only, and not as a rate, some teams reserve 15 to 20% of the build cost per year for maintenance. On a KES 400,000 first release that is roughly KES 60,000 to 80,000 a year before any new features. Use it as a starting figure to test against your own stack and dependencies. If a figure in that region does not fit the business case, it is much cheaper to establish that before the build.

Whether you need an app at all

Compare an installed app, a progressive web app, and a responsive website against expected use frequency, offline requirements, push notifications, device capabilities, distribution needs, authentication, performance, and budget. Where none of the app-specific capabilities are required, a website is usually cheaper to build, cheaper to run, and needs nothing installed.

• Frequent, repeated use, along with offline access, notifications, or a device capability a browser cannot reach, points toward an installed app.
• Occasional use with no offline or device requirement is usually served better by a fast, well-structured website or a progressive web app.
• 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.

Where the requirements are still uncertain, releasing a focused first version and extending it from real usage costs less than building the full feature list first. Scope the first release to the smallest version that does real work, get it into use, and decide the next stage from how it is actually used.