The three rules of SaaS scalability November 19, 2018

The three rules of SaaS scalability

Working at a custom software shop like Metisentry typically means being exposed to a broad array of projects and challenges, a benefit of which is the realization that certain issues emerge with relative frequency, regardless of the nature or purpose of the application.

Among these is the tendency among SaaS product owners to believe that prior development always automatically equates to equity. The conversation usually starts with something like “we’ve already built A and B - we just need you to add C,” the inference being that we’re being asked to build an addition, not an entire house.

And sometimes it is just that simple. But in other cases, it turns out that tearing the the old house down and building a bigger one in its place is more efficient, less costly, and less prone to failure than adding to the existing structure - though it’s almost invariably more costly and time consuming than the owner had imagined. All applications need maintenance or they build varying degrees of technical debt. Sometimes a feature or full rebuild costs less than the accrued maintenance needs.

Those with experience developing SaaS applications might recognize this as a scalability problem. For the uninitiated, scalability is essentially an application’s ability to gracefully accommodate growth in features or capacity. In the example above, “C” represents new functionality, and the application’s owners are faced with deciding between the expense of a complete rewrite, or passing on the new feature.

Such surprises can’t be avoided completely, but they can be mitigated by adhering to three simple rules.

Put the right people in the right roles

Of the roles typically found on a SaaS development team, the product manager and software architect have the greatest impact on scalability.

As the single source of truth in regard to product vision, it’s the product manager’s job to develop a product roadmap plotting out feature and capability enhancements. But doing so isn’t a solitary exercise. He or she must work closely with the software architect, who must design the application in a way that accommodates the growth outlined in the roadmap. When done well, the pair can build a useful roadmap, that’s always expanding the art of the possible and taking full advantage of what is available.

To a lesser, but still meaningful degree, individual developers also impact scalability in their day-to-day work. For example, a developer who writes clean, well organized code and makes frequent use of comments describing the purpose of each functional unit, makes future modifications much easier to implement.

Begin with the end in mind

Of course no one can predict the future, and the rapid pace of innovation, evolving customer priorities and the widespread adoption of agile methodologies all present challenges to avoiding barriers to scalability.

But even then, investing time and money into defining constraints and otherwise planning vetting and documenting a detailed roadmap can pay dividends in the future. For example: how many users should the system support in the final state? How many widgets go through it? Thinking through the constraints and orders of magnitude (1,100,10k,1m) going through the application will help your team build a system that is robust enough to match those needs without overbuilding.

Resist the temptation to “fix it in post” as they say in video circles. Get it right on paper, considering all possible contingencies before writing a line of code. In a nutshell, the idea here is to do anything you can to avoid painting yourself into a costly corner.

Stick to the plan

When you’ve been working on the same application for months or years, it’s easy to get complacent about updating and adhering to a product roadmap that’s starting to feel like a relic. You may start asking yourself if checking every decision against it is really worth it.

When that happens, my advice is to recall Benjamin Franklin’s famous saying, “an ounce of prevention is worth a pound of cure” and remember that it’s been around since 1735 for good reason.

You may have noticed that all three rules revolve around the product roadmap - and that’s not a coincidence. The degree to which a roadmap is well thought-out and adhered to determines whether a development effort yields a useful application or a conglomeration of features, and as such, the key to maintaining SaaS scalability are closely aligned with the map that gets you where you want to go.

Marling Engle

Written by Marling Engle

Metisentry president Marling Engle wrote his first line of code as a curious nine-year-old, and his life has been dedicated to tackling tough problems with software ever since.

Marling founded Metisentry in 2006 after graduating summa cum laude from Kent State University with an MS in Computer Science. He, and his young company, quickly earned a reputation for delivering elegant solutions incorporating high performance, highly-scalable web development, image processing and signal analysis, data mining, and software/system security.

Over the next decade, he started and grew additional ventures, including StationCheck, a SaaS product developed and incubated by Metisentry; while simultaneously expanding the company's capabilities and geographic reach through mergers and acquisitions.

Today, Engle leads Metisentry's team of open-source experts in creating and growing value for client partners through services spanning the entire SaaS product lifecycle.