One of the most asked questions before a SaaS project: "What happens when we grow?" In SMBs you often start with a small pilot – five users, one module, one location. If the solution holds, it should scale to the whole company. Suddenly 5 users become 50, one location becomes five, 100 records per day become 2,000.
A well-designed custom SaaS solution should follow that growth without expensive rebuilds every few months. This article shows which architectural decisions need to be made up front so that scaling does not become a problem later.
Three scaling dimensions
"Scaling" is a multi-layered term. It pays to distinguish three dimensions:
- User scaling: more concurrent users
- Data scaling: more records, larger database
- Functional scaling: more modules, more use cases
These three dimensions need different technical answers. An architecture built for 5 users handles 50 easily – but not if data volume grows a hundredfold in parallel.
Architecture basics that matter later
1. Separating frontend and backend
A modern SaaS architecture cleanly separates the UI (frontend) from the business logic (backend). That has two benefits when scaling: load is distributed across different servers, and the UI can be replaced without affecting the business logic (e.g. when a mobile app is added later).
2. One database, clear models
Most SME applications run on a single relational database (PostgreSQL, MySQL) well beyond 100 users – when the data models are clean. We use only open-source databases so that no lock-in arises later.
3. Plan for caching from the start
Reports, analytics and dashboards are the first places that slow down with growing user/data counts. A cache layer (e.g. Redis) is often only needed later – but it is good if the architecture allows for it from day one.
4. Move long-running jobs out
Slow operations (mass mailings, reports, data exports) should not run inside a browser request. A clean job queue (e.g. with BullMQ or Celery) makes the system robust against load spikes.
5. Decide on multi-tenancy
Will multiple branches, subsidiaries or tenants be administered separately later? If yes, the architecture should support it from day one – otherwise retrofitting is expensive.
Rule of thumb: an architecture designed for 50 users typically still works for 200. One designed for 5 hits its limits at 30.
Hosting scaling: what is actually needed
SMBs often fear that scaling requires expensive cloud architecture (Kubernetes, micro-services, etc.). In most cases that is not true.
Small: 1–20 users
A single server at a German hoster (e.g. Hetzner, IONOS, Open Telekom Cloud). Cost: €30–80/month. Enough for most SME applications for years.
Medium: 20–100 users
A slightly bigger server, or two smaller ones with load balancing. Database on a separate server. Cost: €150–400/month. A second system for testing/staging starts to make sense here.
Large: 100+ users or multiple tenants
Several application servers behind a load balancer, database cluster with replication, dedicated cache and job servers. Cost: €500–1,500/month. Several branches or tenants can be served in parallel.
Important: server scaling is usually cheaper than the additional licence costs of off-the-shelf SaaS. Anyone running 50 users at €199/month hosting pays a fraction of off-the-shelf SaaS at 50 × €79 = €3,950/month.
Performance topics that appear with growth
Slow analytics
A list of 100 records loads quickly. With 10,000 records it noticeably takes longer. Solution: pagination, search indexes in the database, pre-computed analytics.
Concurrent writes
With 5 users it's rare for two to edit the same record. With 50, it happens. Solution: locking mechanisms, versioning, "live update" hints in the frontend.
Mail sending and external APIs
10 mails a day is easy. 5,000 mails a day needs a mail queue with retry logic and a serious sending service (e.g. Postmark, Mailjet).
Backup times
A 100 MB database is backed up in seconds. A 50 GB database needs strategies for incremental backups so the backup process doesn't disrupt operations.
Licence traps that emerge when scaling
Even with custom SaaS there are indirect licence costs that grow with user numbers. We check this explicitly:
- Map services: Google Maps, Mapbox – paid above certain call volumes
- SMS services: billed per message
- Mail sending: per 1,000 mails
- External APIs: weather data, payments, address validation
- Storage: if every user uploads files, it adds up
In an honest proposal these items are listed transparently, with estimates for small, medium and large operations.
Example: scaling in practice
A 2024 Klarspur project illustrates this well: a care service started with 8 users and one location. The system managed shift plans, patient records and billing. Within 18 months three more locations were added; user count grew to 47.
What had to be adjusted?
- Hosting: from a €35 server to two €100 servers with database replication
- Multi-tenancy: was prepared from day one and just needed to be activated
- Shift-plan algorithm: significantly more compute-heavy for 50 employees than for 8 – was optimised (3 days of work)
- Mail volume: switched from internal mail server to a sending service
Total scaling effort from 8 to 47 users: about €4,500 of changes over 18 months. The licence-cost difference vs off-the-shelf SaaS over the same period would have been tens of thousands of euros higher.
When a rebuild really is needed
There are situations where scaling hits limits – even with good architecture. Typical triggers:
- An SME application becomes a platform business (with tens of thousands of external users)
- The business model changes fundamentally
- After 8–10 years the technologies have aged
- Fundamentally new requirements emerge (e.g. real-time IoT data)
In such cases a step-by-step migration to a new generation makes sense – not a big bang. Experience from the old system flows into the new.
Conclusion
Scaling custom SaaS is no secret – it needs a few architectural decisions early on and an honest look at expected growth. Anyone starting with 5 users today but expecting 50 long term should say so clearly in the workshop. The extra cost in initial development is manageable – the savings as you grow are often substantial.
At Klarspur we plan for scaling from day one. Not because every project becomes a platform, but because thoughtful architecture is more durable even at SME scale.
Planning a project with uncertain growth? In the workshop we work out several scenarios with you (5/20/50/100 users) and show what changes technically and economically in each.