Mobile app development
Mobile app development, from the first session to the store.
iOS and Android, the backend behind them, and the design that holds the whole thing together. One team, and one codebase where that makes sense.
App development, end to end
A mobile app is rarely the whole job. There is a backend behind it, an admin side someone on your team has to use, and a set of decisions about what the first version leaves out on purpose. We do all of that, rather than handing you a design file.
That is what app development means here: the product thinking, the interface, the iOS and Android builds, and the server they talk to. Where a piece of it already exists on your side, we build around it.
iOS and Android without building it twice
We build cross-platform, in Flutter, so one codebase ships to the App Store and to Google Play. That is a cost decision before it is a technical one. Two native teams for a first version spends money on engineering instead of on finding out whether anyone wants the product.
Where something genuinely needs native work, it gets native work. The point is not to avoid it, it is to avoid paying for it twice by default.
Getting it into the stores
Publishing is a small project of its own. Both stores want a verified developer account in your company's name, and Apple and Google both hang that on a D-U-N-S number that can take a week to issue. Started late, it is the thing that holds up a finished app.
We handle submission, signing and releases. The accounts stay yours, in your company's name: an app published under a founder's personal account is awkward to move afterwards, and nobody should be sharing that login, us included.
In this order
What happens, and where the cost sits.
The same three phases whatever we are building. What a first version costs is on the how we work page rather than here.
- 01
Two or three sessions, free
We sit down with you and structure the idea before anyone writes code. Who it is for, what the first version has to do, what it leaves out on purpose. Two or three sessions, and there is no invoice for them. You leave with the idea written down, whether or not we build it.
- 02
A first version
Then we build it. Not a clickable prototype: the design, the mobile or web app, and the backend it runs on, in a state real people can use.
- 03
Then reaching a market
Building the product is the part everyone talks about. Getting it in front of people who pay is the part that decides whether it lives. We have done that inside our own companies, and we are extending it to the products we build for founders. It is new for us, and we would rather say so than sell it as a finished service.
What's included
What you get, whatever the scope.
01
The interface, designed
The screens and the route between them, drawn by the same people who build them.
02
One codebase, both stores
iOS and Android from the same Flutter code, with native work where a feature genuinely needs it.
03
The backend and the admin side
The server the app talks to, and the screens someone on your team uses to run it.
04
Store accounts and releases
Submission, signing and updates, on developer accounts that stay in your company's name.
The one we have written up
IFREQ came to us with a football testing protocol and no product. We were their first tech team: the brand, the iOS and Android app, the club-facing web app, the backend, and the scoring behind it.
Read the IFREQ case studyProof
What these products did after launch.
Products we designed and built. Most have no write-up on this site, so these are figures rather than links.
iFREQ : 1m€ ARR
Caredeal : 10k+ downloads
Sized : 100+ brands
Team
Meet the people you'll work with
No account managers in between. The people who design and build it are the people you talk to.
Oscar Fally
Founder · Product & development
Antoine Visart
Design
Elliot Verstraelen
Development
What people ask before a mobile project.
How long does a first version take?
It depends on what is in it, which is what the first sessions are for. That is where the first version gets cut down to something that can reach people quickly, and we would rather quote after them than before.
iOS and Android, or one of them first?
Both, in almost every case. One Flutter codebase ships to both stores, so launching on one platform saves less than people expect and costs you half your audience.
Can you work with a designer we already have?
Yes, and it works best when they sit in the same conversations we do. What does not work is receiving a finished set of screens with no way to ask why a decision was made.
Will you take over an existing app?
Sometimes. Taking over someone else's codebase is a different job from starting one, and whether it is worth doing depends on what is in there. We read it before we answer.
Enough about us, what about you?
Looking for a partner to build your product? Or sitting on a market you know well and cannot build for? Either way, tell us what you are working on.
Let’s talk