When It Comes to Your SaaS Tech Stack, Keep It Simple

When you’re starting a software business from scratch, there are a ton of options for how to build it, and as with anything else, there are trends that come and go, and lots of “experts” who claim one platform or language is superior to all others (although none of them seem to agree). This makes it easy to find yourself stuck in analysis paralysis, get sucked into the excitement of learning something new, or over build too early. While acquiring and operating a full portfolio of SaaS businesses, we’ve learned a lot about what to do and what not to do when it comes to your SaaS tech stack.

‍

Pick the platforms you know (or that a lot of other people do).

‍

If you’re a developer, pick tools you’re comfortable with. A SaaS Founder we acquired from noted, “Many people use side projects to learn new technology, and that’s a great use for learning. But those projects aren’t businesses, they’re learning projects.”

In our experience, Founders wind up with lots of ideas on the shelf because they wanted to learn something new by building a product. That's great if your focus is learning, but if you want to get a product to launch, opting for a familiar toolset will get you there and beyond much more smoothly.

If you’re not a developer, finding one isn’t hard (although finding one who’s also a great teammate is trickier, and we’ll get to that in just a minute), just be sure to pick tools that have the largest communities, like PHP or Ruby on Rails.

When it comes to hosting, you can’t go wrong with AWS, Heroku, or Google. Sticking with the big players in the game makes migration easier down the road, and they have built-in toolsets that developers can use to help expedite deployments.

Just like picking a code platform, you want to use something that has a great community, so when you need more help there are a lot of wonderful people ready to step in.

‍

Hire developers who fit the culture you’re trying to build.

‍

‍

When it comes to the great teammate part, hiring a developer really isn’t different than hiring for any another position — you want someone who fits the culture you’re trying to build. If a developer is eager to learn, fits your culture, and is a great communicator, it’s all gravy from there. On the flip side, don’t be afraid to fire someone if it comes to it. If it’s not working, move fast, and figure out how you can learn from it so you hire better next time.

‍

Iterate, iterate, iterate — in the beginning testing your market fit is much more important than perfecting your tech stack.

Start simple and don’t worry about things breaking. Just accept that they will break and that that’s when learning happens.

In startup scenarios, you should think about building fast and iterating instead of going through lengthy prototyping processes, because working this way gets features in front of potential customers who can give you valuable feedback faster. Ideally, you're distilling down to a simple feature set and getting a product out so you can start getting actionable feedback ASAP.

If you have a feature that clients or customers are clamoring for, build the minimal viable version of it and iterate. In the early stages of a business, it’s all about speed to launch so you can get through the “survival” phase of the startup and start generating some revenue.

Don’t worry about scaling to millions of users, or building extra features you don’t have customers for yet. Just make sure you’ve thought about authorization, and payment (like Stripe), and your most important feature and get it to market. Most modern technical stacks can scale fairly quickly, either by larger instance sizes or distributed nodes across the cloud. Concentrate on keeping your customers happy, building what they need to do their job.

‍

Never tie your front end to your back end.

‍

‍

To put it simply, run your app on a subdomain. Your marketing website and application should always be kept separate. That way if you ever want to take your custom-built homepage and put it into a CMS, you don’t have to hack apart your app to make it work. You can drop it in something like Wordpress and move on.

This also makes hiring for different tasks later on much easier. If you’re dependent on yourself, or a developer to get a blog post published, or change a call-to-action on the homepage to increase conversions, it’ll never happen because there will always be more important development work to do.

And even if you’re handling all of your own content right now, if your business scales the way you want it to, you’ll probably hire marketing help later on. The chances of finding a great marketer who can also dig into your PHP site are slim, but the chances of finding one who’s familiar with WordPress are great.

‍

Don’t reinvent existing SaaS services.

‍

‍

When building your SaaS, don’t reinvent the wheel. There are a lot of great products with wonderful API’s that you can use to handle payments (we already mentioned Stripe), handle support (Help Scout), handle logging (loggly), and handle your exceptions (bugsnag).

Building these yourself may sound like a lot of fun, but in the end it’s much easier to have a helping hand so you can focus on your core business and its core features. Trust us, that will be enough to keep you busy, and you don’t need an extra hat to wear in those early years.

‍

Build to sell (even if you don’t plan on selling).

A lot of founders wind up selling for a lot of different reasons. But not only does building your business in a way that’s easy to sell help with a potential sales process (and your SaaS valuation) down the road, it also typically makes it easier to run your business. It boils down to the fact that 'building to sell' mostly means being well-prepared and organized — things that benefit you today just as much as they would a buyer tomorrow.

When we acquire a company, one of the keys to a smooth transition is having a great developer to assist. And the easiest transitions are always the ones where the dev is truly passionate about the product, the customers, and the code. They want to work with our Tech team to make the process as easy as possible, and if they want to transition out of the business after the exit, they help find a technical replacement.

The hardest acquisitions we see are the ones where there may have been a great idea at the center of the business, but the tech stack was chosen as a learning project. This leads to a lot of messy refactoring in the code as the developers learn.

‍

Keep it simple.

‍

‍

You might notice a recurring theme here in all of our advice. We like to say that “All software tastes like chicken.” Robert Smith said it first, but the point is that you don’t need to overcomplicate the process, the stack, or the architecture. That pretty much always leads to a very messy situation down the road.

And to your customers, what you offer them is features, and hopefully something that makes their lives easier or better. They don’t see (or typically care about) your tech stack. They just see that your product works reliably and provides value (or doesn’t). And you don’t need to set out to revolutionize the software industry to do that.

We have founders who helped save teachers a couple hours a day by improving how they manage feedback and reports. We have another who built a better lead-generation system for SEO agencies. And yet another who thought the spirits industry could offer customers more than walking into a liquor store and picking a bottle off the shelf.

On the surface, these things might not sound transformative, but for their customers, they are. And it’s that value that made those businesses a success. So keep your tech stack simple, and spend your time listening to your customers and really understanding their problems. Find one you can solve, and you’re in business.