Starting from Scratch with a Tech Stack 

07 May 2018

One of the nice things about starting at a new company (or, in this case, starting a new company), is that there’s no baggage. Whatever new technology is out there, as long as it’s not cost-prohibitive, we can kick the tires and give it a shot.

It’s been incredibly freeing and inspiring. Every single point of friction I’ve dealt with in the past is up for discussion on how to eliminate it (or at least mitigate it). Every bit of tech debt, every sunk hardware cost, is all erased.

This freedom can be a little daunting, and can lead to paralysis if you treat every decision as equal. If every choice you make goes through a long, arduous decision tree, demos, a bake-off, negotiations, and, finally, a winner, well, I wish you luck in enjoying your success ten years from now.

But, instead, if you enjoy making quick proofs of concept, making decisions knowing that they’ll work today, but maybe will need to be replaced in a year or two, then you can move fast and take advantage of everything that exists today that didn’t exist the last time you were starting things.

As a small company, the difference between Google and Amazon (and Azure, to be honest), is basically nil. You pick the one that you’ve got the most comfort with, and maybe the one that offers the features you need in some specialized technology (machine learning or kubernetes support, etc.). You buy a billing system rather than build one. You buy mail servers (really, a service) rather than run your own.

The most freeing thing is that I’ve been able to work with our team to bias towards services rather than servers. It’ll cost us more in the short-term, but with a small team, that’s a cost well worth paying. When we’re big enough that the cost matters, we’ll be big enough to hire an ops team to manage a bunch of servers, or, more likely, Amazon/Google will have driven the cost of those services down even more.

As we piece together our architecture, there’s going to be very few pure servers in our stack. API Gateway, Lambdas, Dynamo, ECS/Kubernetes, and S3 will let us build out an entire web application without having to really manage a single server, and (in theory), with a setup that will scale as large and fast as we want.

Once we start driving real customers, we can re-evaluate our pain points (both from performance, maintenance, and cost). But this process lets us get to a customer launch so much faster (and with a smaller team) than it would have been possible just a few years ago.

Along those lines, to do this with a small team, and these pieced together services, you need to have automation baked in. We’ve chosen Terraform for our infrastructure automation, which probably deserves its own post at some point.

But just make sure that you’re not managing your infrastructure and deployments by hand. The tooling is so easy now that having good practices built in on day one will force you to have good habits, and will let your team have a much greater velocity.

In the end, as long as you know that you don’t know everything, you can make intelligent, small bets, move fast, and know that you can replace or improve bad decisions later. ¹