Skip to main content

Cookie preferences

Choose category by category. Nothing is switched on until you switch it on.

Always on

The storage the site needs to work, including remembering this choice. It is not used to track you and cannot be switched off.

Help us understand how the site is used (pages viewed, time spent, where visitors come from), in aggregate figures. Tools: Google Analytics 4.

Services Mobile applications

Building mobile applications

iOS and Android from a single shared codebase, from product scoping to store release, with version upkeep once the app is published.

  • Timeline 3 months minimum
  • Scope set before any proposal

The steps that move the product forward

  1. Scoping and boundaries

    A workshop, then a document that fixes what goes into the first version.

  2. Tested prototype

    The main journeys put in the hands of real people before development.

  3. Two-week cycles

    At the end of every cycle, a version you can install on your phone. You follow the progress without a demo.

  4. Beta, then release

    A small group first, then the fixes, then submission to both stores.

What we put in place

Product scoping

What the first version does, and above all what it does not. An app that tries everything never ships.

Clickable prototype

The screens linked together, usable on a real phone, before any code is written.

One codebase, two stores

iOS and Android held together: a fix is written once, not twice.

Push notifications

The one channel that genuinely brings someone back into an app. As long as it is not overused.

Store release

Listings, screenshots, ratings, developer accounts, review. The part everyone underestimates.

Version upkeep

The platforms change every year, and an app that stops being updated ends up being removed.

When this area makes the difference

  • Businesses whose customers come back often, for whom a website is no longer enough.
  • Field teams that work offline and send data back.
  • Founders who want a first testable version, not a finished product.

The questions worth asking before starting

A shared codebase in the vast majority of cases: the same budget produces two apps instead of one. Native is justified when the app depends on heavy hardware features, and we say so during scoping.

Yes, Apple and Google charge for theirs. They are opened and paid for in your name, not ours: that is what keeps the app yours.

Fixes, compatibility updates and new versions are handled on request. Nothing is committed to in advance.

Also worth a look

Does this format answer your challenge?

Give us a few pointers about your business and your priorities.

Take stock