Five questions to ask when choosing a technology stack for your startup
Almost as dangerous as stating your political or religious opinions online is suggesting software tools and languages for a startup. Software engineers are an opinionated and tribal bunch; say the wrong thing and you’ll be ridiculed and cast out of camp faster than you can say “spaces are better than tabs.”
I’ve written previously about my all-in support and recommendation of the Rails5/Redux/React/ReactNative stack for new startups, but of course this isn’t the right choice for everyone.
To best arrive at an appropriate stack for your startup, I’d suggest asking yourself and your team the following five questions:
#1. WHAT IS YOUR FINANCIAL MODEL?
Not even kidding. Just because you are the tech person doesn’t mean you can ignore the business. Your founding team should know the assumptions and projected income statement, balance sheet, and cash flow situation well enough to infuse this thinking into your product. If your unit economics are based on upgrading as many users as possible to your paid tier, for example, and you need a gazillion users in order to build a sustainable business, then this will affect your stack choice. A business that has a few high-paying clients that won’t actually need to hit the servers very often can get away with a different stack.
#2. WHAT’S THE MINIMUM AMOUNT OF CODE YOU NEED TO WRITE, ESPECIALLY IN THE EARLY DAYS?
The build-versus-buy conversation is an absolute no brainer: buy. If your business requirements and cash position allow, use things like a Database as a Service (DaaS) and WYSIWYG/CMS/CRM/HelpDesk solutions. Don’t write code. Pay other companies as little as possible to manage your tech stack in order to focus on acquiring and retaining happy customers of your own.
For everyone else, think about all the pieces you can outsource (e.g. don’t rebuild Google Analytics). If you’ve done all the research to leverage other software products, then you can begin the process of choosing what languages and tools to use yourself.
#3. WHAT DOES YOUR TEAM KNOW THE BEST?
Are you Microsoft-stack people? Roll with that. Are you hard-core-full-stack JavaScript people? Fine. Avoid the temptation to “learn something new” if it prevents you from rapidly shipping code. What matters is fixing critical bugs and getting the features your users need ASAP.
#4. IS THERE A BIG ENOUGH POOL OF ENGINEERS OUT THERE TO HIRE WHO CAN ROLL WITH YOUR STACK?
You should plan on growing your team, which means you may want to reconsider your Perl back-end on top of your obscure linux distro. Just sayin’.
There’s a reason why going with a relatively mainstream language set and DevOps system is a good idea: you need to hire people, and you need to enjoy working with them (which means the bigger the pool, the better your selection will be).
#5. IS THERE A LARGE ENOUGH COMMUNITY SUPPORTING YOUR STACK CHOICES TO ENSURE BUGS WILL GET FIXED AND THINGS WILL STAY REASONABLY PERFORMANT AS YOU SCALE?
Finally, the performance of your software itself is, of course, critical. Every level of the stack should stay fast and responsive as you scale beyond your forecasted business growth.
This means, for example, that you need to be extremely careful which libraries/packages you choose to incorporate into your code. Are those projects being maintained? When was the last commit? What does the “issues” backlog look like? Are things getting fixed?
Also, you should be able to point to other companies that are taking a similar (if not exact) approach with their software stack. This not only makes your investors and other executives feel a bit better, but it should give you peace of mind that you aren’t being overly crazy with your decisions.
Author’s note: this is the 14th post in a series of articles outlining a framework for startup operations that my partners and I at Prota Ventures have developed. We’re also building a SaaS product on top of this framework to help founders spin up new ventures and get connected to co-founders + advisors/investors along the way. Jump into the private beta queue here. Also, feel free to subscribe to my newsletter and I’ll let you know when I get new content up. Thanks!