You know you want to have something built, but the terms blur together. A web app sounds simple, SaaS sounds scalable, a custom platform sounds expensive. Which one actually fits your situation? In this guide we put the three categories side by side, with concrete prices, lead times, tech stacks and the mistakes we see SMB owners make most often.
What is the difference between a web app, SaaS and a custom platform?
- Web app: an application that runs in the browser, often for one company or a small fixed group of users. Single-tenant.
- SaaS: a product you build to rent to multiple customers on a subscription basis. Multi-tenant.
- Custom platform: an extensive internal system with its own business logic. Not meant to sell, but meant to capture your own processes. Think: the Mastone WWS platform.
When is a web app enough?
- Single-tenant: one company, one installation.
- Limited number of users: often 1 to 50 staff.
- One or two clear flows: a quote generator, a calculator.
- Limited logic: no complicated roles or calculation models.
- Fast ROI needed: payback within a year.
For this kind of build see our websites and dashboards and CMS.
When is SaaS the right choice?
- Multi-tenant architecture with strict data separation.
- Recurring revenue model with subscriptions.
- Self-service onboarding.
- Own marketing and sales funnel.
- Scalable support.
Building SaaS is expensive. An MVP sits at €20,000 to €50,000. According to figures from ProductHunt, dozens of new SaaS products launch every day. We only recommend SaaS once you have market validation.
When is a custom platform the right choice?
- Own business logic: calculation models that exist nowhere else. At Mastone that was WWS point scoring.
- Scale that makes SaaS unaffordable.
- Integrations with legacy systems.
- Compliance and data residency.
- Competitive advantage from your own software.
Custom platforms typically start at €8,000 for an MVP. Full details are in our pillar on having custom software built.
How do the costs differ?
| Type | One-time setup | Per month | 3-year TCO |
|---|---|---|---|
| Web app (simple) | €8,000 to €18,000 | €20 to €60 | €9,000 to €20,000 |
| Web app (extended) | €20,000 to €50,000 | €60 to €200 | €22,000 to €58,000 |
| SaaS (MVP) | €20,000 to €50,000 | €150 to €600 | €25,000 to €72,000 |
| SaaS (full) | €100,000+ | €600 to €2,500 | €120,000+ |
| Custom platform (MVP) | €8,000 to €18,000 | €150 to €500 | €13,000 to €36,000 |
| Custom platform (extended) | €50,000+ | €500 to €1,800 | €68,000+ |
We price at the lower end of these ranges: you pay the lowest amount the scope allows, not the market average.
How do lead times differ?
| Phase | Web app | SaaS (MVP) | Custom platform |
|---|---|---|---|
| Discovery + design | 1 week | 1-2 weeks | 1-2 weeks |
| Build + test | 1-6 weeks | 2-5 weeks | 4-12 weeks |
| Launch + onboarding | 1 week | 1 week | 1-2 weeks |
| Total | 2-8 weeks | 4-8 weeks | 2-4 months |
Our lead times sit at roughly half of what is common in the market. We get there with a fixed team and reusable building blocks, not by cutting corners.
Which tech stack fits which choice?
| Type | Frontend | Backend | Database | Hosting |
|---|---|---|---|---|
| Web app (simple) | Astro or Next.js | Node.js (light API) | Supabase or PostgreSQL | Vercel or Cloudflare |
| Web app (extended) | Next.js + React | Node.js or Python | PostgreSQL | Hetzner VPS or Vercel |
| SaaS (MVP) | Next.js + React | Node.js + tRPC | PostgreSQL with row-level security | Vercel + Supabase + Stripe |
| Custom platform | Next.js or React + Astro | Node.js or Python | PostgreSQL (self-hosted) | Hetzner VPS |
For SaaS specifically we strongly recommend picking Stripe Atlas early for the legal setup.
Which mistake do SMB owners make most often?
- Building SaaS without customers. Start with validation: 10 paying prospects before the build.
- Building a web app where SaaS was intended. Adding multi-tenant later costs double.
- Building a custom platform when SaaS would do. HubSpot Starter is €15 per user per month. A custom CRM costs €20,000+.
How do you choose in 5 minutes?
- Question 1: am I going to sell this to multiple customers on a subscription? Yes = SaaS.
- Question 2: does my company have unique logic that no SaaS package offers? Yes = custom platform.
- Question 3: is there more than €20,000 in budget and do I need multiple modules? Yes = custom platform.
- Question 4: do I have one specific flow and a fixed user group under 50 people? Yes = web app.
- Question 5: can off-the-shelf SaaS solve my problem for less than €100 per month? Yes = buy SaaS, build nothing.
How do you handle data isolation in a SaaS multi-tenant architecture?
In SaaS, data isolation between customers is not a detail. It is the entire core of your architecture. We see three patterns in practice, with widely different costs and complexity. The right choice depends on the number of customers, the sensitivity of the data and compliance requirements.
| Pattern | Isolation | Cost | When |
|---|---|---|---|
| Row-level security (PostgreSQL RLS) | Logical via tenant_id | Low | Up to 5,000 tenants, low-risk data |
| Schema-per-tenant | Separate schema per customer | Medium | Up to 1,000 tenants, medium sensitivity |
| Database-per-tenant | Fully separate database | High | Enterprise, high compliance, data residency |
Which auth and identity approach fits which type?
A web app for 30 employees has a fundamentally different auth layer than a SaaS with self-service signup. Picking this wrong costs a lot of rework later. Below is our standard approach per type, with the parties we use most in 2026.
- Internal web app. Email plus password via Supabase Auth or NextAuth. Optional SSO with Google Workspace or Microsoft Entra ID if the customer already has it.
- B2C SaaS. Self-service signup, email verification, social login (Google, Apple). MFA as an option. Password reset flow is required.
- B2B SaaS. Self-service signup plus team invitations, roles per workspace, SSO via SAML or OIDC for enterprise plans, and SCIM for user provisioning from €500 per month.
- Custom platform. Often SSO linked to an existing identity provider (Azure AD, Okta) plus role-based access at the database level.
For most projects we use Supabase Auth or Clerk. For enterprise SaaS with SAML requirements we look at WorkOS. For the broader frame around ownership see our article on code ownership and vendor lock-in.
Which pricing models fit SaaS, and which pitfalls do we see?
The pricing model is not a marketing detail. It dictates how you build your entire backend. A per-seat model requires user tracking. Usage-based requires accurate metering on API calls or records. Flat-fee is technically simplest but leaves money on the table. Decide this before the first line of code.
| Model | Example | Backend complexity | Best for |
|---|---|---|---|
| Per seat | €15 per user per month | Low (user count) | Productivity, CRM, collaboration |
| Usage-based | €0.001 per API call | High (metering) | Infra tools, AI APIs, mailing |
| Flat tier | €99 per month all-in | Very low | Niche tools, early MVP |
| Hybrid seat plus usage | €15 per seat plus overage | High | Mature B2B SaaS |
When should your web app become a real SaaS?
One of the most common questions we receive is from owners who built an internal tool for one customer and now notice three other companies want the same thing. That is a fine signal, but the step from web app to multi-tenant SaaS is bigger than most people think. Below are the criteria we apply.
- Three or more paying customers ask for the same functionality. Not one, not two. Three.
- The core flow is 80 percent the same across customers. If every customer wants their own industry logic, it stays bespoke.
- There is market validation for at least €5,000 MRR within 6 months.
- The current web app has no multi-tenant data layer. A refactor is needed.
- You have budget and focus for 4 to 8 weeks of build work plus the ongoing marketing and support afterwards.
If fewer than three of these points hold, stay with a web app or a small number of custom platform installations per customer. For the validation approach see our MVP build guide.
What other custom platform examples do we see in practice?
Besides the Mastone WWS point scoring we run into three types of custom platforms regularly with SMB clients. Pattern: always proprietary calculation logic or a process no SaaS package covers, often tied to a physical or administrative flow unique to the industry.
- Bespoke manufacturing company (anonymised). Quote-to-cash platform combining a 14-step quote flow with material calculation and CAD integration. No SaaS package covers this combination of metal-specific variables.
- Regional insurance broker (anonymised). Policy comparison with a proprietary risk scoring model per client. No SaaS CRM had the right data fields.
- Logistics service provider (anonymised). Route-planning platform with proprietary tariff engine and compliance reporting per country. Existing TMS packages lacked the tariff flexibility.
tRPC, REST or GraphQL: which API style fits per type?
The API layer between frontend and backend looks like a purely technical choice, but it shapes development speed, onboarding of new developers and how fast you can ship new features. We see three scenarios for our SMB projects.
| API style | Best for | Pros | Cons |
|---|---|---|---|
| tRPC | TypeScript-only web app or SaaS MVP, small team | End-to-end types, no API docs needed | No external partners consuming the API |
| REST | Custom platform with integrations, partners integrating | Everyone understands it, broad tooling | Boilerplate and manual typing |
| GraphQL | Mature SaaS with complex frontend queries, mobile app | Frontend picks fields, less over-fetching | More complex than REST, heavier server |
Our default for a SaaS MVP is tRPC, since it wins 30 to 50 percent in team speed during the first 6 months. For a custom platform with external integrations we default to REST. We only pick GraphQL when the client has a complex mobile app or a dashboard with many different views.
International scale: GDPR, EU hosting and currency for SaaS
Selling SaaS to customers in Germany, Belgium or France looks obvious, but brings three requirements we often see overlooked in SMB projects. Build these three things in from day one, because adding them later costs double.
- EU data residency. Hosting with an EU provider (we use Hetzner or Vercel with EU region). No US subprocessors without a Data Processing Agreement.
- GDPR right-to-erasure flow. A customer must be able to export or delete their data within 30 days. Build this as an internal admin function from the start.
- Multi-currency and VAT rules. Stripe Tax or Paddle as merchant of record. Belgian customers pay 21 percent VAT, Germans 19 percent, and intra-EU B2B with a valid VAT number 0 percent with reverse charge.
- Languages from launch. At minimum Dutch and English in the interface, otherwise you cut off 40 percent of the EU market.
Why is marketing and a sales funnel only relevant for SaaS?
With a web app or custom platform you build for one client. With SaaS you build a product that has to sell itself to hundreds of customers. That means 30 to 50 percent of your budget goes to acquisition and retention, not to software. Many SMB owners underestimate this and stay stuck in product development.
- Landing pages per persona. No single homepage with all features, but separate pages per use case.
- Self-service signup flow. Onboarding without a sales call, with a trial or freemium tier.
- Activation funnel measurement. Which users become active, which drop off? PostHog or Mixpanel.
- Content marketing and SEO. At least one article per week, otherwise you do not rank in Google.
- Churn management. Measure monthly why customers leave and build on top of that.
Plan for a marketing budget of €2,000 to €10,000 per month from launch, separate from the build cost. For the broader picture on the real cost of software builds see our article on custom software cost and pricing.
Why owners rebuild their web app into SaaS after 2 years
We see a recurring pattern: a web app built for one customer, then 2 or 3 customers added who want copies, and after 18 months the decision to rebuild everything as real multi-tenant SaaS. Below the three reasons we heard most often in 2025 and 2026.
- Per-customer deployments become unmanageable. 5 customers means 5 servers, 5 update rollouts, 5 support cycles per release. Does not scale beyond 10 customers.
- Every customer wants something slightly different. Without feature flags the codebase turns into spaghetti of if-statements per customer.
- Pricing no longer adds up. Selling a copy of a web app for €5,000 leads to the same support load as a SaaS at €500 per month, without the recurring revenue.
How do you start concretely?
Write your problem down on two pages. Walk through the 5-minute decision tree. Plan a free intake call. Our way of working sits in our terms and conditions.
