Mobile App Development

03

From idea to an app on a phone

A mobile project usually begins with something like:

• A service people should be able to use from their pocket
• A business that already runs and needs a mobile channel
• A paper or counter process that should move to a phone
• A way to reach customers who don't sit at a computer
• A product that must handle payments, field work or notifications
• An idea that only makes sense on a device with a camera, location or biometrics

That starting point has to become an app people actually install, open and keep. We work backwards from the one question that decides everything: what must happen on the phone that cannot reasonably happen anywhere else?

04

What the app is for

Before a single screen, we define what the app is supposed to accomplish. That means answering:

• What job does the user give this app?
• How often will they open it — daily, weekly, occasionally?
• Is it a full product or a companion to a bigger system?
• What is the first thing it must do when the phone opens it?
• What happens to a user who installs it and never opens it again?
• What must work even with no connection?
• Where does its data actually live?
• How does the business make money or save money through it?
• What is the smallest version that proves it matters?

Apps that try to be everything usually end up being nothing — great at a demo, forgotten by Tuesday. The discipline is deciding what to deliberately not build.

05

Who is really using it

The person holding the phone is different from the persona in the pitch deck. Some of the realities that change an app:

• They are often on prepaid data — every megabyte has a cost
• Their phone may be entry-level, with limited RAM and storage
• Their OS version may be several generations old
• Their network drops, flaps and switches between 2G, 3G and 4G
• They switch between SIMs and operators
• They share phones within a household
• They expect M-Pesa, PayBill, Till and card payments, because that is how money moves
• English may not be their first language
• They are suspicious of apps that ask for permissions
• They delete apps that are slow, heavy or confusing

If the app is designed for a flagship in a lab, it will not match the person actually using it. We design for the real user from the start instead of discovering the mismatch after launch.

06

Platform strategy: Android, iOS or both

The platform decision is an economic one as much as a technical one. In most Kenyan markets that means:

• Android-first — the majority of the market, the widest device range, the least expensive distribution
• iOS alongside — a smaller but often higher-value audience, with distinct store rules
• Both from one codebase — when the product is genuinely mobile-first and the market justifies both stores
• Web app first — when the audience is reachable through a browser and distribution should be friction-free

We don't default to 'build both' because building both is impressive. We match the platform to the audience, the business model and the maintenance budget the client can actually sustain.

07

Native, cross-platform or web

Each approach trades capability against speed and cost. Our working range:

• Native (Kotlin/Swift) — the deepest access to device features and store performance, at the highest cost
• React Native or Flutter — one codebase, near-native performance, strong device access, our default for most products
• Progressive Web App — installable from the browser, no store, weaker push and payments, ideal for certain audiences

The honest answer depends on the deep device needs, the payment flows, the offline requirement, the team and the budget. There is no universal winner — only the right choice for this product.

08

The first install

An app's hardest conversion is not checkout — it is the first install and the first open. We engineer that moment deliberately:

• App name and icon that read well at thumbnail size
• Store screenshots that show a real screen, not a promise
• A first-run experience that gets the user to value within seconds
• No wall of permissions before the app has shown a scrap of value
• No forced account creation before the user knows what the app does
• Fast cold start — the app should feel alive instantly, not while a spinner spins
• A smooth upgrade path for users coming from an earlier version

The first thirty seconds decide whether the app survives the week. Everything after depends on them.

09

App architecture

A mobile app is a small computer, so its architecture matters as much as the backend's. We set up:

• A clean separation between screens, logic and data
• A navigation structure the user can predict
• A single source of truth for state
• Local storage for everything the phone can own
• A sync layer that merges phone and server reality
• An API layer with retries, timeouts and typed errors
• Environment configuration that cannot ship a test server to production
• Feature flags so releases can be switched on in the field

A well-architected app can ship the next feature in days. A tangled one makes every future change a surgical operation.

10

Offline-first engineering

In Kenya, 'the network is out' is a normal event, not a crisis. The app cannot freeze when that happens. We design systems where the user can:

• Open the app and see their data instantly from local storage
• Continue working while offline — filling forms, capturing photos, starting actions
• Queue every action reliably, in order, with the phone as the source of truth
• Sync automatically the moment a connection returns
• Reconcile conflicting changes without losing anything
• Be told honestly when an action has not yet reached the server
• Retry failed operations instead of silently dropping them

The test of an offline-first app is a full flight to a remote town: no network, then flaky network, then back online — and nothing lost, nothing duplicated, nothing confusing.

11

Network realities

Networks in Kenya are ceaselessly creative. Engineering for them means engineering past the assumption that 'the internet works':

• Requests time out and must be retried with backoff
• Partial responses arrive — a request that 'succeeded' never reached the user
• Connections drop mid-payload, mid-payment, mid-appointment
• DNS resolves slowly or not at all
• The phone hops from Wi-Fi to 4G to 3G mid-session
• Data is expensive — the app must ask before downloading a lot of it

We make every network call idempotent where it matters, so a retry cannot double-charge or double-book. And we give the UI designed, honest states: retrying, waiting for network, saved locally — not an endless spinner.

12

Mobile authentication

Authentication on a phone has more options — and more risk — than a web login. We handle:

• Email or phone + password sign-up and sign-in
• OTP verification over SMS or email
• Biometric unlock with fingerprint or face, backed by a real device key
• Session management that survives app restarts but expires honestly
• Multiple open sessions across the user's devices, visible and revocable
• Account recovery that does not turn into an account hijack
• Device-level protection: app lock, PIN, auto-lock
• One-time passcodes for sensitive actions like withdrawals or verification

The security model of the app is only as strong as its weakest session. We treat phone loss, PIN guessability and shared devices as real scenarios, not edge cases.

13

Mobile security

A phone is a computer that gets lost, borrowed, stolen and sold. Mobile security therefore covers a wider surface than a server's:

• Secure token storage — never plaintext, never in a place other apps can reach
• No secret keys compiled into the app binary
• All traffic over TLS, with pinned or validated certificates where it matters
• Server-side authorization on every API call — the app is not trusted
• Data-at-rest protection on the device for sensitive local data
• Permission discipline — camera, contacts, location only when genuinely required
• Anti-fraud thinking for payments: rate limits, device fingerprints, anomaly checks
• A defined response if secrets or a device are compromised

An app that moves money must behave as if every phone running it is in an enemy's hands. The server does the trusting, the phone does the proving.

14

Biometrics & device trust

The phone's biometrics can make sign-in painless and second-factor security practical. We use them realistically:

• Fingerprint and face unlock mapped to the device's own secure hardware
• Biometrics as a convenience layer over a verified session, not as the only proof of identity
• Sensitive actions — money leaving the account — gated behind re-authentication
• Graceful fallback when the device has no biometrics or the user declines them
• Clear user control: enable, disable, reset the app lock

Biometrics should make security easier to keep on — not become a reason users disable protection.

15

Push notifications

Push is the channel that can bring a user back — or drive them to uninstall. We design it as a discipline, not a feature:

• Push delivered through FCM and APNs with a reliable relay server
• Transaction-critical pushes — money in, money out, confirmations — delivered with priority ties
• Permission requests earned after real value, not screamed at first launch
• User-controlled preferences per notification type
• Graceful handling of an expired or unregistered token
• Deep link from any push into the exact screen that matters
• Rich payloads kept small — a notification is not a file transfer

A notification is a promise the app shows on the user's home screen. We make sure that promise is accurate, relevant and tappable.

16

Deep linking

Users arrive in apps from links all the time — a WhatsApp message, a push, an SMS, a QR code, a referral. Deep linking wires those entry points to the right screen:

• Custom URI schemes and universal/App Links for both platforms
• Cold-start and warm-start handling — the link is opened either way
• Handling links when the app is not installed (routing to the store)
• Payment, booking, meeting and document links that land mid-flow
• Referral links that credit the right account without losing the user
• Sanitised, validated parameters — a deep link is an input, not a trust

17

In-app messaging & support

Customers on a phone expect help without leaving it. We build:

• In-app notifications that mirror or complement push
• Chat with a support team, with history on both sides
• Live activity feeds that explain what just happened — paid, pending, delivered
• Self-service: FAQs, troubleshooting and status inside the app
• Feedback channels that reach the right people without noise
• A human path for money disputes, which no FAQ can replace

18

Camera, photos & documents

The phone's camera is often the fastest input device a business has. We engineer it well:

• Capture that works in poor light and on low-end cameras
• Image compression tuned to the flow — an ID doesn't need a 12-megapixel upload
• Uploads with retry and offline queueing in the field
• File and memory management so a gallery session doesn't kill the app
• Camera permission requested with context, not as a wall
• Display of exactly what the server received, so users trust the result

In Kenya, photo capture is often the KYC flow itself — an ID, a selfie, a receipt. It must work the first time, on the first try, on a cheap phone.

19

Location

Location powers field work, delivery, proximity and mapping features. We handle it with restraint:

• Location only where the feature genuinely needs it
• Coarse-aware design — an approximate fix is often enough
• Budget-conscious background location, where truly required
• Battery-aware updates that don't drain the phone
• Permission prompts that explain exactly why and when
• Graceful degradation when the user denies or the signal dies

20

Background work

Operating systems are hostile to background work — and correctly so. We design around the real constraints:

• Sync, uploads and downloads survive as the foreground app does the visible work
• Heavy work done at the right moment, not opportunistically on dying battery
• OS push constraints respected — the app does not fight the platform
• Completion of critical jobs (a payment, a form) tracked even if the process dies
• Resume logic that picks up where a killed background task stopped

21

Local data & storage

The phone owns a copy of data, and that copy has to be right. We manage it explicitly:

• A local database for structured data so screens stay instant offline
• Key-value and secure storage used for what they are actually for
• Cache eviction that never silently destroys user work
• Storage-budget awareness — a survey app does not need a gigabyte
• A clear story for what happens to local data on logout, deletion or account closure

22

Payments on mobile — the money flow

This is the heart of it. On the phone, paying is supposed to be one tap — so the engineering has to make that tap bulletproof. We integrate the full range of rails the market actually uses, wired into the app with the same discipline in every case:

• M-Pesa via Daraja — the regulated Safaricom gateway, the primary rail in Kenya
• STK Push — the user pays with a PIN on their own phone, with a real charge request fired to Safaricom
• PayBill — customers pay a business number with an account reference, both for deposits and for direct bill settlements
• M-Pesa Till / Lipa na M-Pesa Buy Goods & Services — customer-to-business payments to a Till number or Pochi la Biashara
• C2B — customer-to-business confirmation when money actually arrives at a PayBill or Till
• B2B — business-to-business transfers to a PayBill, Till or merchant account — rent, invoices, bill payments
• B2C — business-to-customer disbursement, sending money out to a phone (withdrawals, payouts, send-money)
• Card payments — Visa, Mastercard and other card rails for e-commerce, top-ups and international customers
• Bank transfer rails — domestic transfer and direct-debit-style flows where the product needs them
• In-app wallets — balances, holds, fees and disbursements settled as the money lands, tied to the same ledger
• Callback handling — every payment response received, verified and idempotent, on every rail

23

Payment transaction engineering

Money cannot be treated like an ordinary database field. Whatever the rail — M-Pesa, cards, bank transfers or wallet — every flow we build follows the same discipline:

• Pending-then-confirmed, never optimistic. The money is not credited on hope.
• Gateway verification. Results are confirmed against the gateway's own query/status API before anything counts — never trusting a single callback blindly.
• Idempotency. A flaky network retrying is normal; a double charge is not. Replays are absorbed, not duplicated, on every rail.
• Terminal-state protection. Once a transaction is final, nothing on earth re-runs it.
• Refund and reversal paths with their own ledgers and notifications, for when things genuinely go wrong.
• Reconciliation. End-of-day totals in the app can be matched line-by-line to the gateway statement — M-Pesa, card or bank.

The test we hold ourselves to on KodiiPay applies to every payment app we build: a user's balance, the ledger, the platform float and the gateway's statement must all agree — and never disagree silently.

The concrete loop we run on every payment-app build:

• Initiate — the app creates a pending transaction with a unique reference and fires one charge request to the gateway (for M-Pesa, an STK push lands on the customer's own phone with the exact amount). Nothing is credited yet.
• Callback arrives — we treat it as a claim, not a proof. The backend queries the gateway's own status/query API and only a genuinely verified ResultCode 0 credits the wallet.
• Transport or query failure — the backend returns the retry signal so the gateway re-sends; the money stays pending, never half-credited.
• Definitive 'not paid' — the callback is acknowledged, the money is never credited, and the discrepancy is written to an audited payment-gateway log for reconciliation.
• Idempotent confirm — replaying the same callback, or the callback arriving twice, can never double-credit: the reference and terminal state absorb it.
• Stale-order sweep — pending payments that a user abandoned mid-flow are expired by a scheduled job that releases any hold, so no money lingers in limbo.
• Exact-shortfall honesty — an insufficient wallet balance returns the exact amount needed to complete the payment (send amount + fee − available), so the user tops up once and succeeds, never guessing.

24

Wallets & balances on the phone

If the app holds balances, it holds trust. We build wallet features into the app discipline:

• Balances rendered from the server's truth, not from stale local cache
• Instant feedback on every movement with a matching ledger entry
• Insufficient-balance errors that tell the user the exact top-up amount — never a vague 'failed'
• Holds, locks and freezes handled visibly: the user always understands their money's state
• Full transaction history, paged and searchable, even for heavy users
• Exact-shortfall top-up inside the flow, so a user is never stranded mid-action

25

Realtime, without the drama

Live updates make an app feel alive, but Kenyan networks punish live-everything. We combine judiciously:

• Realtime channels for the moments that genuinely need them — a payment arriving, a message, a colleague's change
• Polling with backoff as the honest fallback where realtime is not dependable
• Optimistic UI for fast tasks, corrected to server truth within seconds
• A pull-to-refresh and focus-refresh culture everywhere else
• Reconciliation so live events and fetched state never contradict each other

26

Permissions — asked with respect

Every permission screen is a potential uninstall. Our rules:

• Permission requested in context, just before the feature that needs it
• Never a first-run wall of six permissions
• Denials handled gracefully — the feature explains itself instead of freezing
• Permissions reviewed at update time: never re-request without cause
• A visible settings path so users can manage what they granted

27

Device compatibility

The Kenyan device market is wonderfully diverse — and merciless to assumptions. We engineer for it:

• Testing on real, affordable devices across operators and price tiers, not lab flagships
• Minimum-OS decisions based on the target's actual devices, not the newest SDK
• RAM and storage budgets that fit entry-level phones
• Screen-size tolerance from small to large, including the odd aspect ratio
• Hot climates and low battery gracefully handled
• A compatibility matrix that is honest about what the app needs to run

28

Performance engineering

A phone app's performance is felt in the hand, every single day. We budget for it:

• Install size — every megabyte counts on prepaid data and shared phones
• Cold start — the app appears fast or it is judged as broken
• Scrolling and lists — smooth on a mid-range phone with ten thousand rows
• Rendering — minimal main-thread work, lazy images, stable lists
• Battery — no silent background drains that users notice by end of day
• Memory — no crashes on the phone the user can actually afford

The budget is real, measured and tested on the actual devices. A beautiful app that lags on its own market's hardware has failed the most important requirement.

29

App lifecycle & state

A phone user's app gets backgrounded, killed, reopened, updated — constantly. We design the app to be honest at every transition:

• State preserved across background/kill/restore
• Forms not lost when the OS reclaims the app
• Sessions that resume seamlessly after a cold start
• Incomplete actions surfaced ('your payment was interrupted — here is what happened')
• Freshness: the app checks with the server when it returns to the foreground

30

Quality engineering on mobile

Mobile testing is a world of its own. We cover:

• Unit and integration tests on the business logic
• Widget/component tests on the screens
• End-to-end flows on real devices and emulators
• Manual QA on the actual target hardware — old and new
• Network-condition testing: offline, flappy, throttled
• Payment-flow testing against sandbox and staging mirrors
• Crash, memory and performance checked before every release
• Regression testing on every store update

31

App Store & Play Store publishing

Getting to the store is a discipline of its own — and staying live is harder. We handle the full grind:

• Store accounts created and set up in the client's name
• App listing — name, icon, screenshots, descriptions, keywords
• Privacy policies and data-safety declarations that survive review
• Compliance with Play Store and App Store policies, including payments rules
• Signed builds for release, distinct from test builds
• Review submissions and rejections handled without drama
• Gradual rollouts, staged releases and quick rollbacks
• Versioned store updates synced with the app's feature schedule

A store rejection is a normal event in the workflow, not a crisis. We handle the response and the fix as routine engineering.

32

Updates & versioning

An app in the field is a moving target the team must keep steering. We run:

• Semantic versioning and clean release notes
• Forced-update gates when a serious fix can't wait
• Optional-update nudges when the new version is better but not critical
• Feature flags so a release can be controlled remotely without a store round-trip
• Backward compatibility with old clients that haven't updated
• Telemetry on version adoption so the team knows who is actually on the new build

33

Crash reporting & monitoring

The app cannot be silently failing. We wire visibility in from the start:

• Crash reporting with stack traces mapped to versions and devices
• Error tracking that separates app errors from network failures
• Single-screen dashboards for crashes, latency and API health
• Alerting that reaches the team while it matters
• Session data that answers 'did the release make things better or worse?'

34

Analytics on mobile

The phone answers what desktop surveys can't: what are people actually doing?

• Screen views and feature usage by funnel stage
• Install, activation and retention tracked honestly
• Drop-off points identified — where are users leaving?
• Payment funnel analytics: initiation to confirmation, step by step
• User properties relevant to the product — role, account type, KYC status
• Privacy-conscious analytics: no raw PII in event payloads

35

Onboarding

The best feature in the world is worthless if nobody discovers it. We engineer onboarding as a product surface:

• Value shown in the first opening seconds
• Progressive profile-building, not a 40-field signup form
• KYC and verification flows that are clear about what is needed and why
• A guided path to the single most important first action
• Empty states that teach, not walls of grey
• A recovery path for users who abandon onboarding halfway

36

Accessibility on mobile

Reaching users well means reaching all users. We build accessible by default:

• Screen-reader labels on every meaningful control
• Touch targets large enough for real thumbs
• Contrast that survives bright Kenyan sunlight
• Text scaling without layout collapse
• Voice-control and switch-access compatibility where possible
• Colour not used as the only signal for state

37

Localization & language

Kenyans live in English, Kiswahili, Sheng and a dozen mother tongues — often all in one family. We make language a feature:

• All user-visible strings externalised, never hardcoded
• Kiswahili and English supported where the audience needs them
• Number, currency and date formats rendered for the locale
• Payment confirmation language that users trust — KES, safu, jumla
• A path to add more languages without rebuilding

38

In-app support & money disputes

When money is involved, the user will eventually email, call and chat. Support features are part of the product:

• Transaction IDs that both sides can reference with a tap
• A structured dispute path that captures what, when and how much
• Support seen in-app, with the full context behind the user's message
• Status updates revealed to the user instead of radio silence
• Help content written in plain language about fees, holds and refunds

39

Cost engineering on mobile

App costs are real and ongoing. We keep them visible and decidable:

• Push and notification costs, which scale with users
• Payment gateway and transaction fees in the business model
• Backend, storage and bandwidth that grow with the user base
• SMS/verification costs where OTPs run on SMS
• Maintenance, store fees and future update budgets
• Device-testing hardware and tooling

The app must be economically sustainable, not merely technically possible. We design so that success does not silently turn into a cost crisis.

40

Maintaining & evolving

An app is a living asset. We keep it that way:

• OS and dependency updates tracked and applied without breakage
• Store-policy changes (privacy, payments, data safety) monitored
• Seasonal and market-driven feature evolution
• Performance regressions caught before users notice them
• A roadmap that says no as often as it says yes
• Documentation that lets a new developer understand the app in days

41

Scaling mobile products

A successful app creates new problems. We prepare for:

• Users × 10 and transactions × 100 without a rewrite
• Push volume that no longer fits a single queue
• Payment concurrency that needs proper locks, not hope
• Teams that need the codebase to stay comprehensible
• New markets, languages and store requirements
• An architecture that grows in place instead of crumbling

42

The mobile team

Mobile products are built by mobile-shaped people. Our teams bring together:

• Product thinking that weighs every feature against the store and the user
• Cross-platform engineering across React Native and Flutter
• Payment specialists who live across Daraja, PayBill, Till, cards, bank rails, queuing and callbacks
• Designers who know phones, thumbs and hot sun
• QA who test on the devices users actually hold
• Operations who keep stores, pushes and monitors alive

The toolchain

The exact stack we build mobile apps with

We choose boring, proven tools that hire well, survive the next five years and scale without a rewrite. This is the concrete toolchain behind the mobile apps we ship — the same stack KodiiPay itself is built on.

Lifecycle

The mobile product lifecycle

A good app is not a one-time launch. It is a product that has to be installed, used, updated, kept honest and grown — in a market that punishes every lag and every failed payment.

Closing

More than development

Mobile app development connects everything a phone can do into a product people keep. That includes:

A mobile app is not a website smaller. It is a product that lives in a person's pocket, moves their money, answers their questions and has to keep earning the privilege of staying installed.

We build apps for the phone people actually hold — in the network they actually have, moving the money they actually use. That is the standard every screen is held to.