Software you sell, not software you run.
An MVP a real user will pay for — or the SaaS product behind it: accounts, billing, multi-tenancy, and the admin surface that makes it operable. On the web, on iOS and Android, or all three.
start a project→Who this is for
You have something people want, and no software to sell it with yet.
Maybe you have been delivering it by hand for paying customers and it has stopped scaling. Maybe you have a design, a waiting list and no engineer. Maybe you have a v1 built fast by somebody who has since moved on, and every new feature now takes three times as long as the one before it.
What those have in common: the software is the business. When it stops, the revenue stops with it.
What’s included
- Product discovery — what to build first, and just as importantly what to leave out of v1
- Architecture chosen for the next two years rather than for the demo
- The build — front end, API, data model, deployed behind a pipeline
- SaaS foundations — multi-tenancy, accounts, roles and permissions, billing and subscription lifecycle
- Mobile, where the product belongs on a phone — React Native, sharing the API layer and the design tokens with the web app rather than diverging from it
- Operability — onboarding, usage analytics, an admin surface, logging and alerts
- Iteration after release — instrumentation, feedback, and the second version
If it’s an app
One codebase, both stores.
React Native, with native modules where the app genuinely needs them. Not two teams building the same thing twice, and not a website in a wrapper.
Getting in is the hard part, and it’s ours.
Provisioning, signing, TestFlight, the review submission — and the Friday rejection that has to be answered before Monday.
The store listing is made here too.
Screenshots, icon, preview video — designed in the agency that built the app, from the real interface. The screenshots come out of the same agency as the app, rather than out of a brief sent to a stranger.
Then it keeps moving.
Over-the-air updates, push notifications, offline behaviour, and the SDK upgrades the platforms force on you twice a year.
What an MVP means here
Not a demo. Not a clickable prototype. The smallest version a real user will pay for and come back to.
Which means it has the unglamorous parts from the first release: accounts, permissions, a way to take money, a way for you to see what people actually do, and a way to fix it when something breaks at eleven at night.
Cutting those is how a launch turns into a rebuild six months later.
Not a brand, not a campaign, not the photography.
If you need the announcement around the product, that is Launch — and most founders buy the two in sequence rather than at once. And not a co-founder: we build software for a fee. We do not take equity in place of payment, and it is worth saying why — an agency holding equity in six clients prioritises whichever one might exit, which is the opposite of what you want from the people building yours.
A first release in weeks to a few months, depending on what v1 actually has to do.
Scoped in phases rather than quoted once. A product has no finish line — the first release is where the work starts being useful, not where it stops.
Questions
seven answers
01We need a mobile app — is this the right page?
+
We need a mobile app — is this the right page?
+If the app is the thing you sell, yes. If it is a tool your own staff use to do their jobs, that is Platform. If it is a shop, that is Storefront. And if it has to be in the stores on a date with an announcement around it, that is Launch.
02We already have a v1 somebody else built.
+
We already have a v1 somebody else built.
+Start with a paid technical audit: what is there, what it costs to keep, and whether the next year is cheaper spent extending it or replacing it. Sometimes the answer is "keep it and hire your own engineer," and we will say so.
03How small can v1 be?
+
How small can v1 be?
+Smaller than you think. Most of discovery is an argument about what to cut. The test is not whether it is impressive — it is whether one real person will pay for it and use it again next week.
04Is this different from Platform?
+
Is this different from Platform?
+Yes, and it matters for how it is scoped. Platform builds a system that runs your business and ends when the system works. Product builds the thing you sell, and the first release is the beginning. If you are not sure which you are, say what you are trying to do and we will tell you.
05Do we own it?
+
Do we own it?
+Yes. All of it, in your repository, from the first commit. Store developer accounts are registered in your name, not ours — so the app stays yours whoever maintains it next.
06Can you keep building after launch?
+
Can you keep building after launch?
+Usually, and most Product engagements continue as a retained arrangement. It is equally fine if the plan is to hire your own engineers and take it in house — the code is written on the assumption that somebody else will read it.
07Will you use AI in it?
+
Will you use AI in it?
+Where it earns its place, and not where it doesn’t. A model in a product is a running cost and a source of unpredictability, so it needs to be paying for both.
Tell us what you’re trying to do.
start a project→