On this page

Common Mistakes to Avoid When Building a SaaS Application

Common Mistakes to Avoid When Building a SaaS Application

Building a Software-as-a-Service (SaaS) application is a popular and scalable business model, but it comes with a unique set of challenges. In his InfoQ presentation, "Things SaaS Builders Keep Getting Wrong," Jon Topper shares a wealth of experience on the common pitfalls that can derail a SaaS product. This post summarizes the key takeaways from his talk, offering valuable advice for anyone building or scaling a SaaS solution.

1. Building Something Users Don't Want

The most fundamental mistake is building a product that doesn't solve a real problem that users are willing to pay for.

  • Advice:
    • Adopt a Lean startup mindset and optimize for learning.
    • Get to a Minimum Viable Product (MVP) quickly to test your assumptions.
    • Establish a commercial model early and talk to your users frequently.
    • Build continuous delivery practices from the start to iterate quickly.
    • Measure the right things and celebrate learning, not just shipping features.

2. Not Building Tenancy Concepts into Your Application

SaaS is inherently multi-tenanted, and failing to account for this from day one can lead to significant operational complexity and limit your architectural choices.

  • Advice:
    • Bake tenancy concepts into your application from the very beginning.
    • Use foreign keys for tenant IDs in relational databases, or consider row-level security in databases like Postgres.
    • For object storage, embed tenant IDs in the path.
    • Be prepared for larger B2B customers who may require a siloed tenancy model.

3. Not Calculating and Testing Per-Tenant Costs

If you don't know how much it costs to run a single tenant, you can't price your product effectively.

  • Advice:
    • Calculate your baseline per-tenant costs upfront.
    • Ensure that your pricing model covers these costs plus a healthy margin.
    • Be aware that complexity and costs will increase as you add more tenants.

4. Not Automating Tenant Provisioning

Manual tenant provisioning creates bottlenecks and distracts your engineering team from building the product.

  • Advice:
    • Automate tenant provisioning and lifecycle management with a "control plane."
    • This orchestration layer should handle onboarding, billing, configuration, and deployment, separating it from the application itself.

5. Delivering Unique Features or Different Versions to Tenants

Customizing your software for individual customers or allowing them to dictate the update schedule leads to operational complexity and burnout.

  • Advice:
    • Maintain a strong product philosophy and vision.
    • Learn to say "no" strategically to requests that don't align with your product vision.
    • Offer alternatives or integration hooks instead of one-off features.

6. Deploying Your Software into Your Customers' AWS Accounts

This is a common request from enterprise customers, but it's a path fraught with peril.

  • Advice:
    • Push back on these requests.
    • Address customer concerns with clear explanations of your tenancy separation, robust security and architecture documentation, certifications (like ISO 27001), and contractual SLAs.

7. Building Your Solution to Be Multi-Cloud or "Cloud Agnostic"

Trying to be "cloud agnostic" from the start is a premature optimization that leads to duplicated effort and increased complexity.

  • Advice:
    • Focus on one cloud platform and leverage its high-level managed services.
    • Avoid the temptation to re-implement managed services within Kubernetes just to be "agnostic."

8. Deploying Your Solution On-Prem for Customers

This is an outdated model that shifts control to the customer and creates a massive operational burden.

  • Advice:
    • Avoid on-prem deployments whenever possible.
    • The model makes updates and troubleshooting extremely difficult and is a relic of a bygone era.

9. Not Thinking Sufficiently About Backups and Disaster Recovery

Over-optimism about system reliability is a recipe for disaster.

  • Advice:
    • Assume that "everything fails all the time."
    • Conduct "premortems" to identify potential failure modes and prioritize mitigation.
    • Implement a disaster recovery (DR) strategy that is appropriate for your Recovery Point Objective (RPO) and Recovery Time Objective (RTO).

10. Not Classifying Your Data Assets

You can't protect what you don't know you have.

  • Advice:
    • Build a data catalog to track the location, type, security classification, backup frequency, retention policies, and ownership of your data.

Bonus Mistake: Listening to Consultants Instead of Understanding Your Customer Base

External advice can be valuable, but it's not a substitute for understanding your own business and customers.

  • Advice:
    • Make decisions based on what is commercially sensible for your business and your customers, ensuring profitability and avoiding team burnout.

This blog post is a summary of the key points from Jon Topper's InfoQ presentation, "Things SaaS Builders Keep Getting Wrong".