Building SaaS: from idea to MVP to scalable product

Most SaaS projects do not die on technology, but on the assumption that someone wants it. We have built more than 30 products, of which 12 are live SaaS platforms. The common thread among the successful ones: they started small, validated fast and only scaled up once there were paying customers.

Phase 1: validate before you build

Before a single line of code is written, you need to know whether the problem really exists and whether people will pay for it. This sounds obvious, but it is the step that gets skipped most often.

• Talk to ten potential users. Not about your solution, but about their problem.
• Test willingness to pay. "Would you pay €99 per month for this?" tells you more than "do you think this is a good idea?".
• Make a clickable prototype in Figma before you develop. A wizard with mock data says more than ten conversations.

ClaimHandler, our platform for claims experts, started this way. We built out the workflow with one real expert before going broad. That meant the core feature was right from the start.

Phase 2: build a real MVP

An MVP is not half a product, it is a complete product with one core feature that works excellently. The skill is in leaving things out.

If your MVP contains no features you remove afterward, you waited too long to launch.

Our standard stack for SaaS is Laravel 12 with Filament v3.3 for the backend and admin panel, and Next.js 16 for the user interface where needed. Filament delivers a working management panel in days that would otherwise take weeks. That shows up directly in the first invoice.

A first MVP typically costs us €15,000 to €30,000 and is live within two to four months. Not because we run hard, but because we keep the scope strict.

What does and does not belong in an MVP

• Yes: the core feature, user accounts, a basic payment integration, and logging so you can trace problems.
• No: an elaborate permissions system, integrations with ten external tools, a mobile app, or a settings page with forty options.

Phase 3: launch and measure

The launch is the start of the real work. Now you measure what people actually do, not what they said they wanted. Logging on critical flows (uploads, payments, API calls) is essential here: without logs you are fishing in the dark when a customer reports something.

In this phase look at three things: which feature gets used most, where people drop off, and what they really pay for. That determines what you build next.

Phase 4: scale with multi-tenant architecture

Only once you have multiple paying customers do you invest in scale. The core of that is multi-tenant: one codebase serves multiple customers, each with their own walled-off data.

The choices that count here:

• Data isolation: a separate database per customer or a shared database with strict separation. The choice depends on scale and compliance.
• Tenant overrides: customers often want something slightly different. A good architecture allows per-customer deviations without polluting the codebase.
• Monitoring and backups: with paying customers, downtime is lost revenue. We run by default on Hetzner with Cloudflare and daily backups.

IndexNu, our multi-tenant accounting tool, runs on this architecture. Each customer has their own walled-off environment within one platform.

The mistakes that cost money

Three pitfalls we see again and again:

• Building too much for the first customer. Every feature without a paying user is wasted budget.
• Scaling before it is needed. Multi-tenant architecture for zero customers is over-engineering.
• No logging. A production SaaS without logging on critical flows is unmanageable the moment a customer problem arises.

Want to know what your idea realistically costs and how long it takes? Look at our SaaS development approach. We always start with the question of whether the problem is big enough to pay for.

The right technology for each phase

A common mistake is wanting to build the phase-four architecture back in phase two. The technology should grow with the product, not the other way around. This is how we approach it in stages:

• MVP phase: Laravel with Filament delivers a working backend and admin panel at high speed. A simple database, one environment, focus on the core feature.
• Growth phase: Next.js for a fast user interface where it counts, a queue for heavier tasks, and monitoring so you know what is happening.
• Scaling phase: multi-tenant data isolation, caching, and infrastructure that scales with the number of customers.

By choosing the right technology per phase, you do not pay for complexity you do not yet need. An MVP does not need to be scalable for a thousand customers, it needs to prove that ten customers will pay.

Pricing model and payment flow

A SaaS stands or falls on recurring revenue, so the pricing model is no side issue. Think early about how you invoice: per user, per use, or a fixed amount per month. In the MVP phase, build a simple payment integration, not a full invoicing system. Start with manual invoices if that means going live sooner. Only once you have enough customers do you automate the whole payment flow. The goal of the MVP is to prove that people pay, not to build a perfect accounting system.

How you know when to scale up

Scaling up is a decision based on signals, not on gut feeling. The clearest signs: you have multiple paying customers, the current setup is hitting limits (slow queries, manual work that no longer keeps up), and customers ask for features that require more structure. When those signals converge, investing in scale is justified. Do it earlier and you are building for a future that may never arrive.