A common question before a SaaS project (software your team uses in the browser and that runs centrally on a server): “What happens when we grow?” In SMBs you often start with a small pilot – five users, one module, one location. If the software proves itself, it should be rolled out to the whole company quickly. Suddenly 5 users become 50, one location becomes five, 100 records per day become 2,000.
A well-designed custom SaaS application 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. I use only open-source databases so that no dependency on a single vendor (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. Even if hosting for 50 users costs a few hundred euros a month, that is 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. Remedy: pagination (loading lists page by page), 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. Remedy: 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. I 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
An example of how this can look: a care service starts with 8 users and one location. The system manages shift plans, patient records and billing. Within 18 months three more locations are added; the user count grows to 47.
What needs to be adjusted then?
- Hosting: from a €35 server to two €100 servers with database replication
- Multi-tenancy: is prepared from day one and just needs to be activated
- Shift-plan algorithm: significantly more compute-heavy for 50 employees than for 8 – is optimised (about 3 days of work)
- Mail volume: switch from the internal mail server to a sending service
The effort for these adjustments stays manageable – far less than the additional licence fees off-the-shelf SaaS would cause for 47 users over the same period.
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.
When I develop custom software, I 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 together (5/20/50/100 users), and I show you what changes technically and economically in each.