Mobile apps
iOS and Android, native or hybrid. Store publishing, notifications, payments, offline mode when it is needed.

iOS, Android and web, native or hybrid as the project demands. Designed around the gesture that repeats, measured by who returns.
Let's talkHalf of all apps are opened once. The problem is rarely technical: it is an app made for launch day, with ten features in the first release and no reason to come back in week two.
On the other side, internal tools: shared spreadsheets, forms by email and three systems that do not talk, costing hours every day to people who had better things to do.
We start with the gesture that repeats: the one thing the app has to do better than any alternative. The first release does that very well and little else, and reaches real users in weeks.
Then we measure who comes back and why, and every following release is decided by that. Native or hybrid, web or store, is decided by the project and the budget, not by fashion.
iOS and Android, native or hybrid. Store publishing, notifications, payments, offline mode when it is needed.
Back offices, customer portals, members' areas and internal tools that replace spreadsheets and emails.
From clickable prototype to first production release. Real users from early on, features ranked by what they teach.
The service behind the app: authentication, data, integrations with CRM, payments and in-house systems.
Flows designed and tested before the code. One screen fewer is worth more than one feature more.
Releases, operating systems and stores change every year. We stay, with an evolution plan and the cost in plain sight.
Two weeks: who uses it, what repeats, what exists today. Out comes the core gesture and the list of what stays out of the first release.
Clickable flows tested with real users before a line of code. This is where changing your mind is cheap.
Two-week cycles with an installable build at the end of each. The client uses the app while it is being made.
Store publishing, retention measurement and a release plan decided by what users do, not by what was imagined.
Do you have an app idea, or a spreadsheet that should already be one?
Describe the gesture that repeats. We answer with a first reading: native or hybrid, what goes into the first release and what it costs to get there.
It depends on what the app needs from the phone. Camera, sensors, graphics performance or heavy offline use point to native. A content, service or commerce app is well served by hybrid, with one codebase for both stores and half the maintenance cost. We decide during discovery, with the budget in front of us.
Only if there is a repeating gesture the phone does better: notifications, camera, location, quick access. Often the right answer is an installable web app, with no stores and no approvals. We tell you which before proposing.
A well-scoped MVP, three to four months from discovery to publishing. Apple and Google approvals take days when the app is prepared for them from the start.
The app needs someone to maintain it: new operating systems, store rules, dependencies. We propose an evolution plan with monthly hours and priorities decided by measurement.
Ride booking, online auctions, health, discount platforms, neighbourhood and city apps, product customisers for retail. The cases are on the work page.