Mobile applications
Mobile app development for iOS and Android
Native and cross-platform apps, including the ones that have to work offline.
The native or cross-platform question has one honest answer per app, and it depends on what the app does rather than on a house preference. Heavy device integration, demanding graphics or platform-specific interaction patterns argue for native. A form-driven app that has to reach both platforms on one budget argues for cross-platform. We make the call in discovery and explain the reasoning.
For field applications the harder problem is connectivity. An inspector in a county with patchy coverage cannot have the app stall on a network call. Those apps are built offline-first: the local store is the source of truth during the visit, work continues with no signal at all, and sync happens when a connection returns, with explicit rules for what wins when the same record was changed in two places.
Shipping is not the end of it. Store submission, release management, crash reporting and an update pipeline are part of the engagement, because an app that cannot be updated quickly is an app you cannot fix.
What you get
- Platform strategy: native or cross-platform
- Offline-first data layer where needed
- Store submission and release management
- Crash reporting and update pipeline
Who this is for
- Field and inspection teams
- Organisations with a mobile workforce
- Consumer and member-facing services
How the engagement runs
Six steps, in this order.
Skipping one of these is how projects end up rebuilt. The order matters more than the ceremony.
- 01
Consultation
We sit with the people who do the work and find out what actually happens, including the workarounds nobody documented.
- 02
Planning and proposal
Scope, timeline and cost in writing, with the assumptions listed. If something is unknown, it is named as unknown.
- 03
Design and development
Data model first, then interface. You see working software early and often rather than a demo at the end.
- 04
Testing and refinement
Functional, load and user acceptance testing. Findings go on a list that gets closed, not a list that gets discussed.
- 05
Implementation and integration
Migration, integration with existing systems and a cutover plan that accounts for the day the old system is switched off.
- 06
Training and support
Your team is trained on the system they will use, and we stay on for maintenance, updates and the questions that arrive in month three.
Questions
Asked before we start.
Something not covered here? Email us and a person will answer.
Will the app work without a network connection?
If it needs to, yes. Offline-first apps hold their data locally, let the user keep working with no signal, and sync when a connection returns with defined conflict resolution. It costs more than an online-only app, so we only build it that way when the use case genuinely requires it.
Do you publish to the App Store and Google Play?
We handle submission and the review process, publishing under your developer accounts so the listings stay yours. If you do not have accounts yet we will walk your team through setting them up.
Can the app connect to our existing systems?
That is normally the point. The app talks to an API layer over your existing systems, which is often where most of the engineering sits. Where those systems have no API, the integration work is scoped alongside the app.
Scoping
Send us the process that keeps breaking.
A short description is enough to start. We will come back with whether it is a product, a build, or something you can fix without buying software.
Nairobi office
10th Floor, Applewood Adams, Ngong RoadNairobi
Kenya
- Phone
- +254 701 684 754
- Hours
- Mon–Fri, 08:30–17:30 EAT