The phone is where your customers already are.
In Somalia the phone is not a second screen. For most people it is the only screen. That applies to your customers and to your own staff, who are often working in a store room, a vehicle or a market rather than at a desk. A mobile app is worth building when it removes a phone call, a paper form or a trip.
The problem
You already know if you need this.
If more than two of these sound like your business, the problem is structural rather than something to solve with more effort.
- Customers phone you to ask things they could look up themselves.
- Staff in the field write on paper, then re-enter it at the office in the evening.
- You want to reach customers directly instead of through a marketplace.
- Your service depends on knowing where something or someone is right now.
- Payments happen on mobile money, but your records don’t.
What we build
What we build for mobile.
We build for Android first, because that is what your market actually holds, and add iOS where the audience justifies it.
Customer apps
Ordering, balances, booking, delivery status: the things customers currently phone about.
Field staff apps
Data captured where the work happens, working offline and syncing when there is signal.
Delivery & logistics
Job assignment, proof of delivery, and a real answer to “where is my order?”
Mobile money integration
Payments recorded against the right customer automatically instead of reconciled by hand.
Companion apps
A phone front end for an ERP or internal system your team already uses at a desk.
Progressive web apps
When an install is a barrier, a web app that behaves like a native one is often the better answer.
Included
What we design for on purpose
- Low-end Android. We test on cheap, slow devices, because that is what most of your users have.
- Expensive data. Screens are built to be light. An app that eats a user’s bundle gets uninstalled.
- Offline first. The app keeps working without signal and syncs when it returns, rather than showing an error.
- Play Store publishing. We handle the store listing, signing and release process, and hand you the accounts.
- Updates after launch. Phones and operating systems change. An app left alone for two years stops working.
Timelines and figures on this page are indicative. They reflect how projects of this type usually run, not a quote. Anything specific to your business comes after we’ve looked at it.
How a project runs
Discover
We sit with the people doing the work.
Plan
Fixed scope and quote before code.
Build
Working software every two weeks.
Launch
Data migrated, staff trained.
Improve
Supported and changed as you change.
Questions
The things clients actually ask.
Android, iOS, or both?
Android first, in almost every case here. It is the overwhelming majority of devices in the market. We add iOS when the audience genuinely includes it, such as diaspora customers or corporate clients.
Do we need an app, or just a good website?
Often just a good website. An app earns its place when you need offline use, push notifications, the camera, or location. If you don’t need any of those, we will usually recommend a mobile web app instead and save you the cost.
How do users install it?
Through the Google Play Store, which we publish and hand over to you. For internal staff apps, direct distribution is often simpler and avoids review delays.
What does it cost to keep running?
There is a small annual developer account fee, plus whatever your backend hosting costs. The bigger ongoing cost is maintenance: budgeting for updates once or twice a year keeps an app alive.
Does this sound like your business?
Describe what is happening in your own words. We’ll tell you honestly whether this is the right solution, or whether something smaller would do.