Technology · Web and Mobile Applications

An app is only worth what people come back to do in it.

iOS, Android and web, native or hybrid as the project demands. Designed around the gesture that repeats, measured by who returns.

Let's talk

The app that gets installed and the app that gets used

Half 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.

Web and Mobile Applications

What we do in applications

Mobile apps

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

Web applications

Back offices, customer portals, members' areas and internal tools that replace spreadsheets and emails.

Product and MVP

From clickable prototype to first production release. Real users from early on, features ranked by what they teach.

APIs and backend

The service behind the app: authentication, data, integrations with CRM, payments and in-house systems.

Interaction design

Flows designed and tested before the code. One screen fewer is worth more than one feature more.

Maintenance and evolution

Releases, operating systems and stores change every year. We stay, with an evolution plan and the cost in plain sight.

How we work

How an app is born here

  1. Discovery

    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.

  2. Prototype

    Clickable flows tested with real users before a line of code. This is where changing your mind is cheap.

  3. Build

    Two-week cycles with an installable build at the end of each. The client uses the app while it is being made.

  4. Launch and retention

    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.

Start a conversation

Frequently asked questions

Native or hybrid?

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.

I already have a website. Do I need an app?

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.

How long until it is in the stores?

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.

And after launch?

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.

What kind of apps have you built?

Ride booking, online auctions, health, discount platforms, neighbourhood and city apps, product customisers for retail. The cases are on the work page.