Discovery and bounding
Which question does version one answer, for whom, and what is the smallest thing that answers it? The output is a scope you can say no from.
From idea to MVP — built narrow enough to finish.
A first version you can launch, measure and show to users and investors, without version one already being the whole product.
The most common reason a first product never launches is not technology and not budget. It is that the scope was never bounded. Every conversation added a feature, nobody removed one, and twelve months later there is a half-built platform that cannot be shown to anyone.
An MVP is not a cheaper product. It is the smallest version that can give a real answer to the question that decides whether more should be built: does anyone want to use this, and will they pay for it. Anything that does not help answer that question belongs in version two.
We work with founders and with established companies building something new alongside the core business. In both cases the hardest part of the work sits before the code — in deciding what not to build yet.
What is included
Scope is set per project. These are the parts we work on.
Prototype
A clickable flow to put in front of real users before the code starts. Changes here cost hours instead of weeks.
Build and launch
The product built, tested and launched — as web, app or both, depending on where the users actually are.
Measurement from day one
Signup, activation, usage and drop-off measured from launch, so the next decision rests on data rather than impressions.
Material for investors
A product you can demonstrate and numbers you can show. We build the product; the material falls out of it being built and measured.
The path to version two
What was taken out stays in a prioritised list, so the next step is a decision rather than another round of analysis.
How it runs
- IdeaWhat is the assumption that has to hold for this to work?
- BoundingVersion one is defined by what is taken out, with the reason written down.
- PrototypeThe primary flow clickable and tested on real users.
- BuildShort iterations with something runnable in your hands throughout.
- LaunchOut to real users, with measurement in place from the first day.
- DecisionContinue, change direction or stop — based on what the numbers say.
What we build with
Product
- React
- Next.js
- Flutter
- TypeScript
Behind
- Node.js
- PostgreSQL
- Supabase
- Authentication
Commercial
- Stripe
- Subscriptions
- Onboarding
Measurement
- Product analytics
- Event tracking
- Error reporting
A fit if you
- have an idea and need it tested before it becomes a company to run
- need a working product to show investors or a board
- are in a project that has grown so large it no longer finishes
- are an established company building something new beside the core business
- need a technical team until there is a reason to hire your own
MVP & product development
What is an MVP, exactly?
The smallest version that can give a real answer to the question deciding whether the product should be built further — usually whether anyone wants to use it and will pay for it. It is not a cheap or half-finished product: the part that is there has to be fully finished, or you measure how badly something is built rather than whether it is needed. The difference is in how much is included, not in how well it is done.
How long does an MVP take?
Typically a few months from start to launch. What drives it is how hard version one is bounded, not how fast someone codes — which is why we spend the time on bounding first. A scope halved in a meeting saves more time than any decision made later in the project.
What does an MVP cost?
Cost follows scope: the number of user types, whether payments are involved, how many external systems connect, and whether both app and web are needed. We go through it on a free call and come back with a range and the reasoning. The number is often lower than expected, because the scope shrinks during the same call.
What if the idea does not work?
Then it cost an MVP rather than a year, and you know it from real users instead of from a guess. That is the whole point of building small first. We build measurement in from day one precisely so that answer is readable early enough to act on.
Do we own the product and the code?
Yes. Code, accounts, data and environments are yours, handed over in a state where another team can take over. That matters especially for an early product, because an investor’s diligence tends to ask exactly that question.
Can you continue as the product team after launch?
Yes, and many do until there is a reason to hire in-house. We can also build with that as the goal from the start: documentation, structure and handover planned so an internal developer can take over without the product stopping.
What we build — and what you have once it is built.
Web platformsScalable platforms and SaaS products built around real users and real business processes.Mobile appsiOS and Android apps for startups, established companies and any business that meets its customers on a phone.Business systemsDigital systems that streamline operations and connect people, data and process into one place.
Have an idea that needs testing?
Book a free consultation. We go through the idea, what version one should contain, and what should wait.