SaaS (software-as-a-service) development has evolved significantly over the past decade. Traditional desktop applications move to the cloud, and iterate faster due to the limited nature of supported devices and open-source software teams have to maintain.

Desktop applications can now be overcome easily with the adoption of the open-source Electron framework, wrapping around a hosted SaaS solution.

Here’s the list of the top five things technical teams should consider before bootstrapping their own SaaS application.

1. Low-Level Technical Stack
Would a SaaS work better if you pick Java, Ruby, PHP, or C#? Is MySQL a better pick than Oracle or Postgres?

The business plan of your product will point you towards the right technical stack. If you plan to integrate with traditional Microsoft products like SharePoint, an ASP.NET MVC solution running on top of MSSQL may be the right fit. Relying heavily on machine learning may justify starting your product with Python.

2. Robust and Suitable Framework
Aside from the core foundation, growing a high-scale product is contingent on defining the right coding standards, which usually ends up with a flamed discussion on software frameworks.

Often discussed in parallel with the right language or database conversation, selecting a suitable framework can save time, ensure stability due to a lower percentage of regressions, reduce the technical debt over time, and ease the transition across growth phases with fewer senior developers on board.

It’s worth noting that different frameworks and platforms have certain strengths that you may leverage.

AI-driven applications that don’t fit well into MVC may consider Django, a reputable Python framework following a Model-Template-View design architecture, supporting multiple databases with different drivers, and scaffolding an impressive and flexible admin dashboard.

Rapid development teams may pick Ruby on Rails for its well-known “convention over configuration” mission statement. Enterprise-grade engineers who need stability and security over performance often rely on the Java ecosystem and its large suite of frameworks like JSF, Spring and Struts.

Requiring certain paradigms such as parallelization, multithreading, and microservices will turn the scales to some frameworks known for handling such cases well enough.

For instance, I’ve built several SaaS applications on top of WordPress. WordPress may not seem like a suitable (or scalable) choice for SaaS, but I’ve seen it perform well due to its Multisite feature, or the ability to spin up new subsites within a network, sharing the same code base but different database tables. This makes billing and membership plan management extremely well isolated and manageable in the long run. Other tech companies I know of have picked Laravel Spark for a similar reason, offloading billing or invoicing to a separate package built by the founder of Laravel himself.

3. Agility vs. Stability
Building a successful SaaS business may be a sprint or a marathon. Quick Agile sprints require rapid development techniques, whereas slow and cumbersome stacks may not be a good fit. On the other hand, rebuilding your entire stack just when you hit a notable mention on TechCrunch and Mashable thanks to performance leaks may very well ruin your entire brand.

This is why successful SaaS architects consider frameworks that help them iterate quickly while being able to handle massive volumes of traffic and data further down the road.

4. Recruitment and R&D Opportunities
Fast-growing startups must hire and onboard quickly in order to scale. But what if your local market lacks the talent you need?

Perl may be a great language for parsing regular expressions and managing hashes, but how many Perl engineers work in your city? And how common it is for a seasoned developer to pick a job as a Perl developer?

Same goes for bleeding-edge languages and frameworks. If Dart or Go seem like a great alternative, think twice about their adoption and longevity. You may be one of their early adopters (and success stories) but it’s a gamble that may affect your long-term growth. Sure, some banks are known to run production code on COBOL and Fortran, but it’s not like fresh graduates are dying to land a job as COBOL developers nowadays.

5. Investment and Exit Goals
Fueling your SaaS may require external investors. And aiming for a successful exit means that your codebase matters, too.

On one hand, picking a hot language or a framework may be a trigger for angel investors or well-known engineering VCs to bet on your startup. But it’s a tricky bet. Also, picking a truly unique technical stack may make you less valuable to certain companies interested in acquiring a similar business.

LinkedIn was built on top of .NET and Microsoft acquired it. Would Microsoft take over LinkedIn and keep funding it if it was built on Java, its known nemesis in the enterprise development space?

Your investment and exit goals should align with your technical stack.