We help founders and product teams define a first SaaS release that proves the product, then design and build it properly—so it becomes the foundation of the platform rather than something you replace a year later. We've done this with our own product as well as for clients.
Our own MVP, Resova, launched with a single venue and grew into a platform serving 1,000+ venues in 20+ countries.
An MVP gets used to mean two different things, and the difference matters. One is a demo: something that looks like the product, proves nothing commercially, and can't be given to a paying customer. The other is a first release—narrow, but genuinely usable, with a real customer doing the core job end to end and paying for the privilege.
We build the second kind. That means one primary journey done properly, the account and permission basics around it, whatever billing the pricing model actually needs, and very little else. Everything you can defer is deferred—not dropped, just sequenced after you know more than you do today.
The reason to be this strict is that an MVP's real output isn't the software. It's the information: what customers do with it, what they ignore, what they ask for, and whether they pay. Every feature you add before launch delays that information and increases the chance you built it on a guess.
Four questions we put every proposed feature through. Most of them fail at the first one, which is the point.
If yes, it waits. This one question removes more from a first release than anything else, and almost nothing survives it that genuinely needed to. The features people fight hardest for are often the ones nobody misses in the first month.
Requirements get built. Assumptions get tested, which is usually much cheaper—a prototype, a conversation with five prospects, or simply shipping without it and seeing whether anyone asks.
A small category of things genuinely must be settled early—tenancy, the access model, how billing maps to pricing. Those aren't features and they don't get cut. Everything else can be added to good foundations.
Sign-up, the core job, and getting billed have to work. A beautiful workflow with no route to revenue tells you nothing about whether you have a business, which was the entire point of launching early.
Who the users are, the job they repeat, the commercial model, and which beliefs about all three are actually assumptions.
The scope for release one, what's deliberately deferred, and the reasoning written down so it survives month two.
The core journeys, clickable, before anything is engineered—the cheapest point to find out you were wrong.
Engineering on foundations that hold—tenancy, permissions, billing—with working software in front of you throughout.
Real customers, close attention to what they actually do, and a roadmap rebuilt on evidence instead of assumptions.
That's usually the first thing discovery settles, and it's worth an hour of conversation before anyone writes a proposal. If you already know you're building the whole thing, our SaaS development work covers that end to end.
Resova started as a gap we found doing someone else's job. Breakout needed online booking for a new escape room venue, and nothing on the market fitted how attractions actually operate. Building a booking platform for an entire industry was the ambition; launching one with a single venue was the MVP.
So we cut hard. Discovery covered both user groups—guests booking and operators running the venue—and the first release covered exactly two things properly: a fast, mobile-first guest checkout, and a back office where staff could manage bookings, schedules and payments without training. No marketing automation, no multi-venue reporting, no integrations beyond payments. We prototyped both journeys before engineering them, and we settled tenancy, permissions and payment handling properly even at that size, because those are the decisions that force rewrites.
It launched alongside Breakout's opening and processed hundreds of bookings within weeks. What those early venues did with it—and asked for—set the roadmap far better than our original plan had. Resova went on to serve over 1,000 venues across more than 20 countries and process billions of dollars in payments before being acquired by ClubSpeed.
None of the foundations laid in that first release had to be torn out. That's the test of an MVP, and it's why we're strict about the distinction between a narrow scope and a throwaway build.
Read the Resova case studyThe part that decides everything downstream. We work through the users and the job they're trying to finish, the commercial model behind the subscription, the constraints you're working within, and—most usefully—which of your current beliefs are assumptions worth testing rather than requirements worth building. You come out with a defined first release, a sequenced roadmap for what follows, and the reasoning behind both.
We design and prototype the journeys that make up the first release, so you can click through the product and use it before a line of it is engineered. It's the cheapest moment to find out that a workflow doesn't match how people work—and the most useful thing to put in front of prospective customers or investors, who respond to something they can use far better than a description of it. Our product design work goes into this in more detail.
A narrow scope, built properly. We engineer the core workflows and the foundations they sit on—tenancy, accounts, roles and permissions, and whatever billing the pricing model requires—on an architecture chosen for where the product is going rather than only where it starts. Delivery is iterative, so you see working software early and often instead of waiting for one handover at the end.
Getting it live is a milestone, not the finish. We monitor how the product behaves and how people use it, and turn that into the next set of decisions: what to build, what to fix, and what you can now stop planning because nobody wants it. This is where an MVP earns its keep—if you don't act on what it tells you, you've just built a small product slowly instead of a big one.
The most common failure is a first release that grew. Every stakeholder adds the one thing they can't live without, nobody is empowered to say no, and twelve months later there's a large, unlaunched product built entirely on assumptions. The cost isn't only the budget; it's the year of learning you didn't get. Scope discipline is unpopular in the moment and it's the single highest-value thing an outside team can bring.
The opposite failure: shipping fast by skipping the things that are expensive to retrofit. Tenancy bolted onto a product that assumed one customer, permissions added after the fact, billing that doesn't fit the pricing model. These aren't features you can add later cheaply—they're structural. A good MVP is narrow in surface and sound underneath, which is a harder balance than either extreme.
A first release with no way to sign up, subscribe or be billed can't answer the question you built it to answer. Willingness to pay is the finding that matters, and you only get it by asking for money. Free pilots tell you people will accept something free. Plenty of MVPs launch with a polished core workflow and a manual, apologetic billing process bolted on the side, and learn much less than they should.
The point of an MVP is the information. If the roadmap after launch is the same roadmap you wrote before it, the exercise was theatre. Real customers reliably contradict at least one thing everybody was certain about, and the teams that get the most out of a first release are the ones willing to drop planned work on the strength of what actually happened.
A first release narrow enough to build quickly, but complete enough that a real customer can do the core job end to end and pay you for it. That last part matters. A prototype nobody can use, or a product with a great workflow and no way to sign up or be billed, does not tell you anything commercially. In practice a SaaS MVP usually means one primary user journey done properly, the account and permission basics around it, whatever billing the pricing model needs, and very little else. Everything you can defer is deferred—not dropped, just sequenced after you know more.
We separate what proves the product from what merely improves it. The test for any feature is whether the first customers can get value without it: if they can, it waits. Then we look at what is an assumption rather than a requirement, because assumptions are cheaper to test than to build. The output is a defined scope with the reasoning attached, so when someone asks in month two why a feature is not there, the answer is written down rather than remembered. We would rather argue about this properly in discovery than discover it halfway through engineering.
It depends almost entirely on how much has to exist on day one, which is why scope is the conversation we have first. A single core journey with simple permissions and one payment integration is a very different proposition to a platform with several user types, reporting and third-party integrations before it launches at all. We estimate after discovery and MVP definition, once the scope, the user journeys and the technical approach are agreed, rather than committing to a date before anyone knows what is being built. We have written about what actually drives the timeline in more detail in our insights section.
Cost follows scope, so we give a range against a defined brief rather than a figure up front. The things that move it most are the number of distinct user journeys, how many roles and permission levels are needed, how much integration work is involved, and how much design and discovery is required before engineering starts. The useful thing to know is that scope discipline is the biggest lever you have on cost—a first release with one journey done well typically costs a fraction of one that tries to cover three, and it teaches you more per pound because it reaches customers sooner.
It should not, and avoiding that is largely an architecture decision made at the start. A narrow scope is not the same thing as a throwaway build. The parts that are expensive to retrofit—how tenants and their data are separated, how roles and permissions work, how billing fits the pricing model—get settled properly even in a first release, because those are the decisions that force rewrites. What we keep deliberately minimal is feature surface, not foundations. That is the difference between an MVP you build on and a prototype you throw away.
Yes, and it is usually the highest-value part of the process. We prototype the core journeys so you can click through the product and use it before any of it is engineered. That is the cheapest possible moment to discover that a workflow does not match how people actually work, or that two features everyone argued about are both unnecessary. Prototypes are also the most useful thing to put in front of prospective customers or investors, because they respond to something they can use rather than a description of it.
The point of an MVP is what it teaches you, so the weeks after launch are the most valuable part of the whole exercise. We watch how people actually use it, where they stop, what they ask for and what they ignore, and work through the roadmap with you on that evidence rather than the original assumptions. Some of what you planned for release two turns out not to matter; something nobody listed becomes the priority. We support products long term, so the same team carries the product forward instead of handing it over.
Yes—Resova, which is the reason we talk about MVP scope the way we do. We defined a first release narrow enough to launch alongside one venue: a fast mobile-first guest checkout and a back office where staff could manage bookings without training. It processed hundreds of bookings in its first weeks, and what those early venues did with it shaped everything that followed. It went on to serve over 1,000 venues in more than 20 countries before being acquired by ClubSpeed. We carried the commercial risk on that scope decision ourselves, which is a different kind of experience from advising on one.
Bring us the idea, the market you're aiming at and whatever you've got so far—a document, a prototype, a spreadsheet, or just a strong opinion. The first conversation is about what the first release needs to prove, not a pitch.
Scope your MVPPrefer email? hello@walkerthomason.com