At QCon London 2025, AWS Ambassador Jon Topper delivered a talk on common mistakes that companies make when building SaaS (Software as a Service) solutions.
“Building, deploying, and operating software is hard, and that goes double when you’re building SaaS,” said Topper, the founder of The Scale Factory (now part of Ten10). A recurring theme of his talk was how teams can often accidentally make lives extra complicated for their future selves. He said how much wisdom can come from communities and user groups, “they allow us to heed people’s lessons and understand their mistakes before we make them ourselves.”
Topper began his talk by explaining how traditional software may be shipped out on media or as discrete downloadable artefacts for users to install as they wish, but SaaS solutions come with the complexity of being fundamentally designed for hosting multiple tenants. He pointed out the scale of SaaS in the contemporary software space: half of the venture capital deployed into companies worldwide in 2024 went into SaaS businesses according to Dealroom.
Topper urged people to think about architecting for multi-tenancy right from the start. He explained that many SaaS products evolve from enterprise applications intended for a single tenant and ventured that not considering multi-tenancy at the start can significantly hinder scaling options later on. He also suggested immediately calculating the baseline costs per tenant and making sure that these fit in at the price point that the market needs.
If you’re not thinking about tenancy on day one, you’re walking into only being able to build the silo model.
Reflecting on the fact that development teams are usually busy innovating and iterating on new features, it usually falls to them to provision environments for new potential customers, and this can often be low on their priorities. So Topper advises automating tenant provisioning early on to avoid the development team being a bottleneck for the commercial side of the business.
Turning to how actually to build SaaS applications in the cloud, Topper described three main architectural models: the “pool” model, where everything is shared, the “silo” model, where each customer has unique dedicated infrastructure, and a “bridge” model option in the middle where some resources are shared but some are dedicated per customer. He stated that regulatory requirements in industries such as healthcare, life sciences and finance can sometimes drive people towards the silo model, noting that the silo model has higher baseline costs and is more complicated, but provides the most isolation.
He conceptualised SaaS architecture as having two components: the application plane (web application, services, API gateway, database) and the control plane (orchestration layer, tenant onboarding, billing automation). He strongly advocated using AWS Control Tower and Landing Zones to provide security guardrails and consistency across accounts.
Topper warned strongly on the dangers of per-customer customisations and allowing customers to mandate release timings. “Delivering unique features or different versions to tenants will kill ops teams if you’re not careful.” He advocated for a strong product philosophy that includes being comfortable with the “strategic no” when customers ask for features that don’t align with the current product roadmap.
If you allow customers to dictate when or where software updates happen, then you’re baking in operational complexity and sacrificing your weekends.
He also advised against deploying software into customers’ AWS accounts despite customer requests, explaining that “philosophically this isn’t really SaaS – it’s just selling software,” and to avoid trying to be multi-cloud; “as an early-stage business, you shouldn’t be worried about building on more than one platform until you’ve saturated the market for people who will buy the AWS version.”
Topper recommended doing proper disaster recovery and security planning, citing AWS CTO Werner Vogels’ wisdom that “everything fails all the time”. He suggested doing pre-mortem exercises to make a start on this. On the topic of data, he proposed building a security model based on developing an understanding of where their data is and who has responsibility for it.
TL;DR: Jon Topper’s ten things people get wrong when building SaaS applications:
- Building something users don’t want
- Not building tenancy concepts into application components
- Not calculating baseline per-tenant costs and testing this with the market
- Not automating tenant provisioning
- Delivering unique features or different versions to tenants
- Deploying your software into your customers’ AWS accounts
- Building your solution to be multi-cloud or cloud-agnostic
- Deploying your solution on-premise for customers
- Not thinking sufficiently about backups and disaster recovery
- Not classifying data assets
- Listening to consultants instead of understanding your customer base
