Build a SaaS, from MVP to scalable platform

Plan for 8 to 12 weeks from the moment scope and design are locked. What drives that timeline: the number of flows a user has to complete, whether real-time functionality is involved and how unusual your business logic is. Faster is possible, but almost always means leaving out functionality that returns after the first customer conversations anyway. If planning runs past twelve weeks, that is a signal the scope is no longer an MVP but version 1.0. In the proposal we therefore split explicitly what sits in the first release and what is on the list for after it.

A serious B2B SaaS MVP costs 25,000 to 60,000 euros. The phase after it, where you build what customers actually use, usually costs 30,000 to 80,000 euros. A scalable version with multi-tenancy, automated billing and analytics comes to 60,000 to 150,000 euros. From idea to scalable platform that is 120,000 to 290,000 euros, spread over one to two years. Do not forget the recurring costs: 200 to 1,500 euros per month for hosting and 200 to 600 euros for services like monitoring, transactional email and analytics. Below 25,000 euros we end up compromising on security or architecture, and you pay for that twice over in year two.

Three. In the MVP phase of 8 to 12 weeks we build only the core that lets your first ten customers solve their problem; the goal is proof that people pay. In the validation phase of three to six months you build what usage and customer conversations reveal, and we pay down the debt the MVP deliberately took on. From around month nine the scale phase follows: tenant separation, self-service onboarding, automated billing, team accounts and analytics. The mistake we see most often is trying to build phase three during phase one, so the money runs out before there is a paying customer.

That depends on how your first customers arrive. If you expect ten larger customers in year one that you onboard yourself, a simpler setup is fine and you migrate later. If you expect self-service signups from day one, tenant separation has to be right immediately, because retrofitting means redesigning the data layer with real customer data in it. What we always set up correctly from the start is that every row of data has an owner and that authorisation is enforced at database level, not only in the interface. That is the cheap half of multi-tenancy and the most expensive part to repair later.

Stripe is stronger on subscription logic: trials, plan changes, usage-based billing, per-country VAT handling and a portal where customers manage their own subscription. Mollie fits Dutch payment habits better with iDEAL and SEPA direct debit, is sharper on transaction fees and has a dashboard a non-technical founder understands. If you sell mainly in the Netherlands with monthly direct debit, Mollie covers the whole need. If you have international ambition or a complex pricing model, Stripe saves you months of build work. A fuller comparison sits at /vergelijking/stripe-vs-mollie.

Our strength is B2B: software with accounts per organisation, roles, invoices and a buying process where someone has to justify a decision. Consumer SaaS runs on different mechanics, with growth through app stores and virality, conversion at micro level and margins that only work at large volumes. We say honestly in the first conversation whether your idea falls there. If it does, an agency working on retention and growth loops every day is a better partner than we are.

Then we take on that part of the role: architecture choices, security, vendor selection and explaining which decision costs money now and which only later. You keep the market, pricing and customer contact in your own hands, because we cannot validate those for you. In practice that means a fixed weekly session, decisions recorded in writing in plain language, and access to every environment in your name. What we are not: an incubator that builds for equity or arranges your funding. We are a development team that understands you need to explain to customers and investors what has been built.

We deliberately accept debt that is cheap to reverse: manual onboarding, an admin screen that is functional but ugly, reports that still come from a query instead of a dashboard, and limited test coverage on edge cases. Everything we postpone goes on a list with the reason attached. What we do not do is debt that touches the foundation: no ownership on data, no migration path in the database, keys or passwords in the code, or a payment integration that cannot handle failed payments. That is not debt but a future rebuild with customers already paying.

Four, and they are hard to reverse later: how you handle identity and access, how tenants are separated, how subscriptions and billing fit the data model, and how you ship new functionality without breaking existing customers. We discuss those four before the first line of code, because they determine what version two will cost. The concrete choice of framework, database or hosting party comes afterwards and follows from your situation, your team and where your data is allowed to live. We have preferences, but no fixed template that pushes every product into the same shape.

You do, and for a SaaS that is more than a principle. Your product is a business asset you want to be able to sell, put through due diligence or hand to an in-house team. That is why everything is in your name from day one: repositories in your organisation, hosting, database, payment account and domains on your own accounts, with us as developer with scoped rights. In an acquisition or funding round you do not have to set up an escrow arrangement or ask a supplier for permission. We also deliver documentation that survives a technical due diligence without us in the room.

A retainer from 2,500 euros per month covers security updates, dependency maintenance, monitoring and small fixes. As your platform grows the monthly budget grows with it, because most of the time then goes to new functionality and customer requests rather than maintenance. What the arrangement contains concretely we agree per situation: response times, who gets called during an incident and whether we also handle first-line questions from your customers. If you have enterprise customers with an SLA yourself, we mirror those obligations so you do not make a promise that is not technically covered.

Three things. No product whose idea has never been put in front of a potential customer; a few weeks in the market is worth more than the first sprint. No marketing website called SaaS because it has a login; that is a website with a form and costs a fraction. And no platform whose business case leans on hundreds of thousands of free users with no paid model behind it. For the first two we are glad to point you in the right direction, even when that means it does not become an assignment.