My approach to SaaS architecture

Architecture decisions that actually matter

Architecture is a deep topic, and how a product is built at the technical level depends entirely on what it needs to do. How many users will it serve? What's the computational load? Does it need to integrate with other services? These questions and dozens more influence how your product is actually built.

But here's what I've learnt: the 80/20 principle applies to architecture just as much as it does to features. A few really important decisions will have the greatest impact. Everything else is detail.

The over-engineering trap

What we absolutely don't want with a new product is to over-engineer it. It's remarkably easy for software engineers - myself included - to overcomplicate things. It's a constant battle to resist the urge to do too much.

Let me give you a concrete example. Say you're building an application to manage end-of-tenancy surveys and reports for property management. You tell me, "We want to build this product and expect to have 1,000 users on the platform."

As engineers, our minds immediately jump to: "Right, 1,000 users means we need load balancers, multiple servers, fancy cloud technology, special databases, caching systems, message queues..." The list goes on. We start designing for 1,000 or maybe even 10,000 users with room to spare.

The reality check

Here's the missing part: out of the gate, you won't have 1,000 or 10,000 customers. You might have one. You might have ten. You might have zero for the first few months. All those grand architectural plans? They're expensive, complicated, and completely redundant for your actual needs.

I've seen projects spend months building infrastructure for thousands of concurrent users, only to have twelve people sign up in the first year. That's not just wasted money - it's wasted time that could have been spent improving the product for those twelve users. This is exactly the kind of development waste I work to minimise.

The worst part? Your product might never reach 10,000 users. It might peak at 100, and that's fine - many successful businesses operate at that scale. It might reach 500 and be wonderfully profitable. All that extra engineering work to handle more was a complete waste of time and money.

Finding the Goldilocks solution

On the flip side, we can't build something that falls over when the eleventh customer signs up. That's not enough flexibility. What we need is the "baby bear's porridge" solution - not too big, not too small, but just right.

Finding this balance requires understanding exactly what your product needs to do, not what it might theoretically need to do someday. It's about building for your next six months, not your next six years.

My pragmatic approach

Here's how I approach SaaS architecture for new projects:

Start with proven foundations I use Laravel as my framework because it provides solid architectural patterns out of the box. Multi-tenancy, queuing, caching - it's all there when we need it, but doesn't get in the way when we don't.

Design for hundreds, not thousands I architect systems that can comfortably handle a few hundred active users. This covers 90% of products in their first year. The architecture allows for growth, but we're not paying for it upfront.

Use boring technology PostgreSQL, Redis, and tried-and-tested tools. No experimental databases or bleeding-edge solutions. Boring technology is reliable technology.

Make scaling predictable When growth happens, the path forward is clear. Database can be scaled vertically first, then horizontally. Application servers can be added behind a load balancer. Caching can be enhanced. Each step is well-understood and can be implemented when needed.

The self-funding growth model

The beauty of starting smaller is that once you get your first 50 or 100 customers, their licence fees fund the expansion. Need better infrastructure to handle growth? Great - you've got revenue to pay for it. This is infinitely better than guessing at requirements and building expensive infrastructure that sits idle. It's the same principle I use for keeping projects within budget.

I've helped clients grow from ten users to thousands using this approach. At each stage, we invested in architecture improvements funded by actual revenue. No waste, no over-engineering, just pragmatic growth.

Real architectural priorities

Instead of building for imaginary scale, I focus on architectural decisions that matter immediately:

Data isolation: Ensuring customer data is properly separated from day one. This is non-negotiable for security and compliance.

Backup and recovery: Your ten customers care more about not losing their data than whether you can handle ten thousand more.

Deployment simplicity: Being able to deploy updates quickly and safely matters more than exotic scaling capabilities.

Monitoring and observability: Knowing what's happening in your application helps you make informed decisions about when to scale.

Code organisation: Clean, maintainable code that allows for future changes without complete rewrites.

The incremental scaling path

When products do need to scale, it happens incrementally:

1. Optimise what you have: Often, simple optimisations can 10x your capacity
2. Vertical scaling: Bigger servers solve most problems up to thousands of users
3. Caching layer: Redis or similar can dramatically reduce database load
4. Read replicas: Separate read and write database operations
5. Horizontal scaling: Only when truly needed, add more application servers
6. Microservices: Only for specific bottlenecks, not as a default architecture

Each step is taken when justified by actual usage, not architectural astronautics.

Avoiding the rewrite trap

It's entirely possible to architect products in a way that past a certain point, the whole thing needs rewriting. This is what we want to avoid. By choosing proven patterns and maintaining clean code, even significant architectural changes can be made incrementally.

The key is not trying to be too clever upfront. Simple, well-understood patterns can take you surprisingly far. When you do need to evolve the architecture, you'll have the revenue and user feedback to guide decisions.

Walking before running

Starting smaller and growing with your user base isn't just financially sensible - it's technically superior. You build what you actually need, when you need it. Your architecture evolves based on real usage patterns, not imaginary scenarios.

Unless you've already got thousands of customers waiting or a massive marketing budget ready to deploy, build for where you are, not where you dream of being. One step at a time. Let's walk before we start trying to run.