Having a great idea isn’t enough when you’re starting a startup. You have to execute well on that idea by making the right decisions at the right time. In particular, you have to pick the right tech stack for your product. Without a good technical foundation, you can end up accumulating a lot of technical debt.
So to help founders understand what a good tech stack should look like, we invited two experts on this topic, Preeti Somal, the EVP of Engineering at HashiCorp and Jill Wetzler, the VP of Engineering at Pilot, to TechCrunch Disrupt 2021 to discuss everything from evaluating vendors to making sure you can rely on an open source product.
Making sure your team can ship quickly
Some development environments are more familiar than others. For instance, if you choose to work with a popular framework, it’ll be easier to find engineers to join your team, and the learning curve will be easier for your existing developers.
Your tech stack isn’t limited to the language your team is using. Choosing a good CI/CD (continuous integration and continuous delivery) framework can help you release updates more frequently. Using test suites is also a key element of a good development pipeline.
“I looked at how we were thinking about developer productivity and our environment. What are the things that can help our team move really fast and ship really fast? Because I think that is the name of the game when you’re talking about a startup. It just comes down to how you can get your code out the door as quickly as possible,” Wetzler said.
Wetzler knows what she’s talking about on this front as she experienced the opposite of that in a previous job when she was working for Twitter. “Twitter was making some decisions that I think were based on some people’s personal preferences at the time. We started to fork our own versions of git and our build system as well. It just became a mess that had to be untangled over a number of years. And so you really do pay for those decisions down the line,” she said.
The ability to reuse your code across different platforms can also help you manage multiple projects more easily. That can be important if you’re in charge of the roadmap and you want to have some visibility when you’re planning the next quarter.
“We had done a really good job of making some investments in our back-end productivity. But when it came to front end, we were really missing a lot of the key infrastructure pieces that helped us build a front end really quickly,” Wetzler said. She worked on fixing that when she joined Pilot.
Picking the right tools
HashiCorp is the company behind the popular infrastructure product Terraform. The company provides an open source version of Terraform and also works with other companies as a vendor. That’s why Somal has a unique perspective on evaluating third-party vendors before you start working with them.
“The role we play is taking care of all of those infrastructure capabilities so that customers can really focus on their business logic and building their application. A lot of the areas that we get asked about is on being open source,” Somal said. “How healthy is the community? If I pick a tool like Terraform, how do I know that tool has the longevity and I’m not going to need to go and replace it at some point in time? Also, there are a lot of considerations around how you grow with me,” she added.
HashiCorp itself is built on open source components, so the company uses the same mental framework to evaluate open source pieces for its own tech stack. We went over the technical capabilities of open source components — do they perform well and are they reliable?
We also discussed the viability and longevity of tech decisions when it comes to open source. “What’s the community like? How much effort will we need to put in to support this? Is it possible for us to be a member of that community and help build that component further? What’s the security elements of this?” Somal said.
Jill Wetzler doubled down on the idea that you shouldn’t skip the security review, even when you’re just starting. At Pilot, the company initially chose to partner with a third-party company for security reviews.
“There are companies out there that you can contract with that will essentially work as your security team. And that’s what we chose to do early on being a company that has lots of financial data from our customers. It is very important for us to take security seriously,” Wetzler said. “We’re able to send our vendors through them and work with them on best security practices and pass along their feedback to the vendors that we’re considering using,” she added.
You can also take advantage of industry practices to get a sense of the security of a product. For instance, if you’re considering a vendor and they already work with well-known names in the tech industry, you know they have already gone through some due diligence process on the security front. “If we see Microsoft or Salesforce or Stripe using an open source project, that at least eliminates one barrier. Some of these companies have built a really strong product offering that is very security conscious. We do go through our own analysis, but it just gives you a really strong foundation,” Somal said.
Understanding technical debt
Everybody talks about avoiding technical debt, but it’s not a binary discussion. For instance, when you’re building a minimum viable product, chances are you’re looking for shortcuts even though you know that you’ll have to address those decisions later.
“The reality is, when you’re very small, you’re bootstrapping and you’re trying to get something out of the door; you’re creating technical debt for yourself. I think it’s really important to be honest with yourself [that] you’re creating debt that you’ll need to address later. And sometimes it’s the right move,” Jill Wetzler said.
Essentially, you always have to evaluate how long your current system is going to last. As your company gets bigger, you can swap out parts of your products with newer parts that will last longer.
“People have found different techniques. For instance, one of the techniques was, if you’re in an area of code and you see tech debt, just fix it then or start a sprint. All you’re doing that sprint is working off your tech debt backlog. I think the really key thing is to recognize it, find a strategy to work with it, and don’t let it build to a point where it just feels like you’re going to take a massive hit on productivity,” Somal said.
At a broader scale, you have to engage with the product team to make sure that you have the right culture around tech debt. The product team has to take into account tech debt in the overall roadmap. That’s the best way to have an honest discussion about the current state of your product and the next steps.
