Cost to Build a Custom Mobile App

Someone on the board says, “We need an app.” Someone else says, “How much?” Then the conversation stalls - because “an app” can mean a simple booking screen or a full offline field tool with payments, roles, and reports. If you are trying to price the cost to build a custom mobile app for a shop, SACCO, clinic, or distribution team in Kenya, you need bands and drivers, not a magic number from a tweet.

This article breaks the budget into pieces you can actually quote, negotiate, and defend. For the wider build-vs-buy picture, start with the complete guide to custom software for SMEs in Kenya.

What “cost” usually includes (and what people forget)

A serious quote is not just “developer days × rate.” Plan for:

1. Discovery and scope - workshops, process mapping, written requirements.
2. Design - flows, screens, empty states, error states staff will actually hit.
3. Build - iOS, Android, or both; often a backend and admin panel too.
4. Integrations - M-Pesa, SMS, email, bank files, your existing POS or Excel exports.
5. Testing and UAT - your team clicking through real scenarios.
6. Store release - Apple and Google accounts, review cycles, signing certificates.
7. Hosting and operations - servers, backups, monitoring after launch.
8. Support window - bug fixes in the first weeks when real users arrive.

Skip any of those in the quote and you will meet them later as “change requests.” For the costs that never appear on the first invoice, read hidden costs of app development.

Budget bands for planning (KES, always [VERIFY])

Use these as planning envelopes, not fixed prices. Replace with written quotes labelled [VERIFY] before you commit board money.

Scope shape	What it roughly covers	Planning envelope (KES)
Focused MVP	1–2 user roles, 5–8 core screens, one main workflow, limited admin	[VERIFY] 800,000 – 2,500,000
Operational tool	Multiple roles, reports, one payment or SMS integration, solid admin	[VERIFY] 2,500,000 – 6,000,000
Multi-branch / complex	Offline needs, several integrations, audit trails, richer reporting	[VERIFY] 6,000,000+

Android-only is often cheaper than iOS + Android with full feature parity. A “wrapper around a website” can look cheap and fail in the field (camera offline, slow forms, poor push notifications). Ask vendors to spell out native vs hybrid trade-offs in writing.

The six drivers that move price the most

1. Number of roles and screens

A member app that only views balances is not the same as an admin app that edits loans, plus a field officer mode. Every role multiplies flows, permissions, and edge cases.

2. Offline and weak connectivity

Many Kenyan routes and branches do not have perfect data. Offline sync, conflict resolution, and “queue until online” are engineering work, not a toggle. Budget for it if the app must work in the field.

3. Payments and messaging

M-Pesa (STK, C2B, B2C), card gateways, SMS OTPs, and delivery receipts all need sandbox testing, error handling, and reconciliation views. Cheap demos often skip the failure paths your cashier will hit on a busy Saturday.

4. Data migration

If you are leaving Excel, AccPac exports, or a legacy member list, cleaning and importing data is a project of its own. Bad migration destroys trust in a new app faster than a slow screen.

5. App stores vs internal distribution

Public store apps need privacy policies, content ratings, and review time. Internal staff apps can sometimes use alternative distribution - still budget for device management and updates.

6. Who owns the code and hosting

Clarify: source code escrow or handover, cloud account ownership, API keys, and who pays monthly infrastructure. A low build price with vendor lock-in on hosting can cost more over three years.

Phasing so the budget survives the board meeting

You rarely need every feature on day one. A sane sequence for many SMEs:

1. Core transaction - the one workflow that hurts most (orders, collections, attendance).
2. Admin and reports - so managers stop chasing WhatsApp screenshots.
3. Integrations - payments and SMS once the core is stable.
4. Nice-to-haves - dark mode, fancy charts, second language polish.

Phasing is how you build a quality app on a limited budget without pretending quality is free. Cut scope first; cutting testing is how you pay twice.

Questions to put in every RFP

• What is in scope for v1, and what is explicitly out of scope?
• Which platforms (Android / iOS / web admin) and which versions do you support?
• How many environments (dev / staging / production)?
• Who pays Google Play / Apple Developer fees annually?
• What is the warranty period after go-live?
• What is the monthly hosting and support retainer after launch? ([VERIFY] rates vary widely.)
• Do we receive full source code and deployment docs?
• How do you handle change requests - rate card or re-estimate?

Get answers in a document you can show finance, not only in a slide deck.

Kenya-specific realities that affect cost

• Device mix - support mid-range Android phones, not only flagship demos.
• Mobile money first - payment edge cases matter more than “checkout with Visa” screenshots.
• Training time - budget staff training days; unpaid overtime is still a cost.
• Tax and receipts - if the app issues invoices or member statements, involve your accountant early.
• Data protection - sensitive SACCO or HR data needs access control and a retention plan; treat this as scope, not a footnote.

How to compare two quotes fairly

Do not pick the cheaper number if scopes differ. Align vendors on the same acceptance list: screens, roles, integrations, offline, reports, handover. Then compare:

• Clarity of scope (vague quotes hide risk)
• Timeline realism (aggressive dates often mean unpaid overtime later)
• Testing depth
• Post-launch support
• References you can call (without inventing testimonials - ask for real contacts)

If one quote is half the other, ask what they removed: design, UAT, offline, or documentation.

A simple internal checklist before you approve spend

• Problem statement fits on one page
• Success metric defined (e.g. reduce order errors, cut reconciliation time)
• v1 scope written and signed by an internal owner
• Budget includes discovery + build + launch + 3–6 months support
• Integration list named (M-Pesa, SMS, ERP, etc.)
• Data migration owner assigned
• Hosting and code ownership decided
• Contingency of 15–25% for discoveries during build ([VERIFY] with your finance policy)

Bottom line

The cost to build a custom mobile app is a range driven by roles, offline needs, integrations, and how much quality you insist on at launch. Use planning bands in KES, insist on written scope, and phase features so cash flow matches learning. When you are ready to frame the whole decision - product vs custom, hire vs partner - return to the custom software guide for Kenyan SMEs and pressure-test the soft costs in hidden costs of app development.