Making Tech Choices: Don’t Add Risk to an Already Risky Business

Reading Time: 7 minutes

As technical founders, we’re supposed to choose the technology that works best for us and our business. But we often let the cargo-culting around the newest, hottest tech stack get to us. Many technical founders see a new startup as an opportunity to figure out a modern tech stack. That is a dangerous move. Not only do you have to deal with the inherently hazardous nature of creating a new business, but now there is also the chance that the new and mostly untested tech stack might not be able to solve the problem you’re trying to solve.

The central question of choosing one particular technology over another is this: “Will you be able to use this well for a long time?”

There are three components to this question: your technical aptitude as a founder, your ability to use the technology for your particular purpose, and how you can minimize the chance of having to replace it later. Let’s look into each aspect in detail, starting with how compatible you, the founder, are with the technology.

Founder-Technology-Fit

When in doubt, stick to what you know. If you have built your last four projects with Laravel, the chances are that your business might benefit more from you getting up to speed quickly in Laravel than spending three months figuring out how to learn a different programming language like Golang. With new technology come new paradigms and best practices, and it takes a long time to assimilate all this information.

When looking at a tech stack or service, ask yourself if you’re able to evaluate it properly. You may know a lot about building SaaS tools. Still, you might not have the expertise to judge whether a particular database will perform better for the specific kind of data and query logic you will need for your service. For some technologies, you can run a little experiment. Others you will need to use for more extended periods to develop an understanding. Best ask fellow founders about their experiences with any particular technology that you don’t have any personal experience with yourself.

It may be tempting to choose to learn a new technology that supposedly is the perfect fit for your project. In rare cases, this is the right course of action, because the fit is just too good to be ignored. In most other cases, however, you’re overestimating the technology and underestimating your own skills. If you can code using one technology, you will be able to build almost anything using the knowledge you already have. This will be your advantage. You can jump right into building the product without needing to learn anything new.

Purpose-Technology-Fit

Particularly with newly available technology, you will often only see the “happy path,” the use cases the technology has been developed for. This can lead to blind spots in your evaluation: you just don’t know what hasn’t been discovered yet. Over time, these solutions will encounter edge cases and performance problems, which will eventually be resolved. But it’s likely that you don’t want to be the one discovering these problems and having to wait for a solution.

The more specific a technical solution, the more likely it will not be optimal for any usage patterns that lie outside this particular niche. Over-optimized solutions might look appealing, but the moment your business requirements change, you might be left with a technology that is unwieldy and unable to do the job.

For data storage systems like databases, use tried and tested systems like PostgreSQL unless your business absolutely needs a different kind of storage. Postgres has been adopting the right parts of NoSQL and Time Series databases over the last few versions, so there is no need to experiment with systems that may not scale well in production. You don’t want to encounter performance bottlenecks because the system you’re using has not been used at a specific scale before.

I have learned to look at generalists more favorably over time. I’m not talking about one-size-fits-all solutions here; I mean the kinds of technologies that have evolved from their edge-case-only usage towards more adaptable products. Redis, for example, is a generalist in the specialized niche of caching solutions. Most of the time, you recognize the generalists by the simplicity of the interface they offer. The more it looks like a collection of simple building blocks, the better.

I’ve fallen into the specialist trap before. When we started FeedbackPanda, I was looking for a cloud hosting provider capable of orchestrating Docker containers. I thought the big cloud providers were not specific enough with their hosted Kubernetes offerings, so I picked a small infrastructure startup that promised to allow interacting with Docker containers through their dashboards and GUIs instead of having to use command-line calls. I was thrilled and set up our production system on their platform. For a while, it went well, but then, their service experienced a few problems. Those little hiccups turned into full-on outages, lasting for hours. I had no choice but to move our production system onto a major cloud provider overnight. Ever since then, the system has run without a second of downtime. The more generalist option of a cloud-hosted Kubernetes turned out to be the more stable choice. And it turned out I could integrate the command-line calls much better into our release pipeline than the clicks on dashboards and user interfaces.

Going with a generalist solution might require more work on your end initially, but it will also reduce the number of surprises that may wait for you in your future. Often, generalists have many very different users, and therefore have to build systems that can handle a lot of different ways of being used. This results in resilient systems that can be made to fit individual purposes without making it harder for others to use them differently. 

Technology Durability

One of the worst things that can happen to a SaaS business is when a crucial part of your tech stack breaks away at a later stage of your business. That is a risk that you can never fully get rid of, but you can minimize it.

To be on the safe side, choose popular technology. Many developers using a certain framework or stack will mean that more bugs are discovered over time, and this kind of software is often very well-maintained. The best way to quickly find out if a particular piece of software is popular is to look for documentation and educational resources. If there are a lot of tutorials and the technology seems well-documented at first glance, it will likely be around for quite a while.

Look for a vibrant community. I’ve noticed that in the Elixir/Phoenix community: developers were very engaged, they loved spending time on educating other developers about the intricacies of this functional programming language and the ecosystem. 

When you’re new to a programming language or just not as advanced as you need to be to solve your problem, you will have to learn the lay of the land before you can dive into building your product: what are the libraries you will need to use for certain parts? What are the best practices? Why were things done the way they are done? You’ll learn all these things very quickly if there are excellent educational resources provided by the makers of the technology and the communities that form around it.

Maturity is also an essential property of good technology. If people have been using something for a few years, you can expect it to be reliable, mostly bug-free, and performant both for low and high usage patterns. There are often good indicators for the maturity of a technology: feature-completeness, ability to integrate with other solutions and workflows, and the breath of use-cases it’s been tested in. For databases, you will find that there are some tried and tested options like PostgreSQL, which has been around since 1996 and is being used in businesses of all sizes, including Netflix, Spotify, and Uber.

I made the mistake of building a business on an immaturely selected database once. I picked a fancy newly developed NoSQL database that was lauded for it’s real-time capabilities by the early adopters. What I found out a few months into the development is that I really needed a relational database that was performant under a heavy query load. All the real-time features were irrelevant when I noticed that this new technology wasn’t designed to handle the kind of usage that our application required. I learned a valuable lesson that day that I carried into FeedbackPanda: for your core technology, boring is better.

In general, I would advise against learning a new technology stack by building a business around it. There are two goals here, and they don’t align well: building a stable business that will survive for a long time and learning a technology that may or may not be a passing fad. This extends to the services you use as well.

Remember the Docker hosting startups I mentioned above that we had to migrate away from in a hurry? They exhibited another risky behavior: uncertainty about the future presence of a service. At some point, after we had already migrated away, we received an email stating that they were shutting down the service, with two weeks’ notice, urging all current customers to migrate their products elsewhere. Then, a few months later, we received another email stating that they’d found a new investor to help them restart their service. Now they asked customers to come back. While ridiculously unprofessional, this was an important lesson for me. There is a real risk in choosing immature services and technologies.

Guidelines to Pick A Technology

Over the years, I have collected a list of attributes that technology should exhibit to be a good fit. It doesn’t have to have them all, but if it misses more marks than it hits, it might not be the right choice for a bootstrapped business. You’ll have enough work on your hands from serving a niche audience with a likely ever-changing problem. You don’t need to worry about your tech stack at the same time.

Technology that you can use well for a long time has these attributes:

• It can be used to solve your problem. You can find stories of how other businesses have used this technology to fulfill a similar need to yours. You can evaluate the technology without spending months of your time.
• It’s popular. You find a lot of resources and opinions about it on the web. There are books on the technology for beginners and experts alike.
• It’s surrounded by vibrant communities. There are forums, Twitter communities, whole Slack instances dedicated to the technology, and they’re active.
• It’s reliable. You can find a lot of established businesses that use it in their production systems without too many disastrous stories. 
• It’s scalable. Small business and big businesses are using this technology.
• It’s extensible. You can find a lot of libraries and integrations for the technology. You can also find information on how you can get them to work.
• It’s mature. You can find a history of how the technology was adapted to fulfil the real needs of the people using it.
• It’s well-maintained. You can find recent and regular updates to the service, either in a changelog or in the source code itself. People who report their problems are responded to, and their concerns addressed.
• It’s replaceable. You can find alternatives to the technology that you can use in its stead should it become problematic or ineffective.

If a technology you’re looking at checks all or most of these boxes, use it. If not, look for one that does. If you do this for all the choices you will need to make, you’ll end up with a very maintainable collection of technologies that will stand the test of time.