When choosing a tech stack, look before you leap

When it comes to choosing a tech stack, the decisions you make today could have a cascading impact for years. On one hand you want to be cool and modern, but on the other, you want to build with technology you know — and sometimes getting to market is more important than riding the latest technology wave.

The problem is that your decisions can have consequences that result in technical debt, the concept that as you make one decision, you have to pay a debt of sorts to fix underlying structural problems in the code as the result of those decisions you made early on.

Before you start freaking out, it’s something that happens to every company and is really impossible to avoid — so you make your choices and get your product out the door.

At this week’s TechCrunch Early Stage conference, HappyFunCorp CEO and co-founder Ben Schippers and CTO Jon Evans spoke about choosing the optimal tech stack. The pair have built custom software for companies like Amazon, Samsung, WeWork and AMC, so they know a thing or two about the subject.

What to consider before choosing

Evans says startups must weigh several key factors when choosing a tech stack, but development speed tops the list. “The single most key thing about your tech stack is speed,” he said. “The right stack will give you the most speed, compared to the alternatives.”

But early choices have other implications. “In the medium- to long-run, you have to be conscious about running up what we call technical debt, which is really the side effects of a spaghetti nest of bad code that is tightly coupled and leads to negative side effects all over the place,” he said.

That can slow you down in the future. “Suddenly it takes days to fix bugs and it takes weeks to add features, and it takes months to pivot to something new. That’s not a good place to be, particularly if you’re a startup still trying to pivot and looking for new things to try,” warned Evans.

Founders should also weigh the benefits of building from scratch against using open source or connecting with an API. Using time-tested options as opposed to building something yourself and tying up valuable development resources can be more strategic. Instead of building a payment gateway, for example, you might use a popular open-source library or something like Stripe.

Another factor to consider: The choices you make now could have an impact on whether people want to work for you. It’s hard to find good engineers, and they often want to work on cutting-edge stuff that will be interesting to them and advance their careers. If you’re working on something a bit more established, it could turn some potential talent off, so that’s something you’ll need to take into account.

Finally, consider scalability. Simplicity could get you to market faster, but you could pay a price down the road if you need to scale up to handle significantly more users or data.

It’s a balancing act

While you have to balance all of these factors, you also need to consider the needs and requirements of your prospective customers.

“There’s a lot of sparring that always happens in the programming arena around the newest and greatest JavaScript, the newest and greatest blockchain, the newest and greatest whatever — and that’s fine and good, but as it relates to product awareness and building something that will eventually scale, we tend to think about time to market, and it’s really important to get to market as fast as you can,” Schippers said.

He says that it’s probably best to go with what you’re familiar with for starters because startups often have to refactor as they go. Get the product out the door, assess what’s happening with it and adjust as needed.

You also have to consider if you’re building a web app, a mobile app or both. “Another major question is how many platforms. So if you are trying to just build for the web, that’s one solution. If you’re trying to build for the web, for Android and for iOS, which is what most people are trying to do, looking at a JavaScript framework […] might make sense,” Schippers said. “And then again be constantly asking yourself these product questions, not just building technology for technology’s sake.”

Get something done and fix it later

As you consider all this, don’t fret too much about your choices. Evans and Schippers said a founder’s first job is to get something done. After it’s out the door, you can think about fixing it, even throwing out everything you did to get to that point.

In fact, they describe refactoring as a critical (and normal) part of the development process. “You should expect to refactor. Refactoring is critical. Jon and I always say that if we can get people 75% to 80% of the way there for whatever it is we’re trying to build, we’re doing great,” he said.

He says that if you go in with that attitude, it gives you a lot more flexibility in your thinking because you’re not necessarily going to be tied forever to your first choice. “You know you’re going to refactor no matter what, so you can build something in PHP, or you can build something in dotnet, or you can build something on Rails, and there’s nothing wrong with saying, ‘I’m going to throw this out once I figure out what I’m doing.’ Now it might hurt, but that’s the reality of the situation,” he said.

Keep in mind, even large well-established companies have rebuilt their tech stacks when it became untenable. Sometimes the technical debt becomes just too big to handle and you have to change course. You can’t know that when you launch your startup, but just because the tech stack is a major decision doesn’t mean you’re locked in forever. What it does mean is that you have to balance a lot of competing factors. At some point, you make your decision and you go build.

Your first job is always releasing a product and making sure it’s usable. While your tech stack surely matters, it’s just one factor to consider as you build your company.