Motivation

If you’ve gotten this far, thank you. Taking the time to be here means a lot.

What is Monolith?

As I have time, I will research and share how startups, defined loosely, developed their product before they had meaningful traction. Each post will be a deep dive on a single company. I hope to do this between once and twice a month.

The content won’t be a bullet list of technologies, but instead will explore engineering details that I (and hopefully you) find interesting. As one, better known, example: Facebook didn’t have any unit tests until 2009. They had well over 100M daily active users at that point.

My hope is that I can craft this newsletter together with you. As I write these, please let me know what is interesting and is not including the idea of this newsletter itself. As with a startup, my approach here is to get something out and then iterate to make it better.

Why Monolith?

When I started as a developer, microservices were the hot new thing. Netflix famously broke up their monolith into microservices in 2009 amid scaling issues. Even though the company I joined was started in 2008, the software we developed had an old school architecture. We shipped a virtual image that customers deployed and managed in their own data centers. I was interested in starting a company myself one day, but felt like I needed to learn how “modern applications” were built beforehand. In hindsight, it’s clear this was just insecurity and fear, but, at the time, I went looking.

The next company I joined was exactly what I was looking for. I was one of the first 10 employees and was working on a product that hadn’t shipped yet. I was excited! We developed microservices in multiple languages, had a React web app, and a native iOS app. A year in we were also running an API gateway, a Kafka message queue, and Kubernetes. All of that work was unnecessary. We never crossed 10k MAUs during my time there.

I was lucky to meet some amazing mentors there who taught me how to build at startups. Moving Fast by Jeff Meyerson also had a major impact on me and is part the inspiration for Monolith.

For me the simple insight of the last two years is all that matters in a startup is building something that some people value.

In meme form:

In famous Marc Andreessen quote form:

The development at most pre-product market fit startups should be simple and boring. Software is a tool to create value and the value of very few products come from solving difficult technical problems. Just as an example, the top 5 private YC companies are Stripe, Instacart, OpenSea, Faire, and Brex. None of these required solving difficult engineering problems in order to provide initial value. This isn’t to say they didn’t have to solve difficult engineering problems as they scaled, but the primary value driver of each of these companies was not a complicated engineering problem. For pre-product market fit companies, spending time on future engineering problems is time not spent on the current problem: not being valuable. Instead, simplicity should be the bias in development.

Paul Graham speaks about simplicity in Taste for Makers:

All the ornate engineering I mentioned above: using microservices, learning Go, deploying an API gateway, etc. was cope for me. All these things made me feel like I was doing the right thing which was comforting in the ambiguity of a pre-product market fit company. The engineers at Netflix are idolized and Netflix uses microservices so if I use microservices then I’m one step closer to being like Netflix, right? The difference though was Netflix had a technical problem when they implemented microservices, we had a value problem.

As my engineering mindset has shifted to being value focused, I’ve found myself looking for examples of how other companies built something in the early stages. The vast majority of engineering resources discuss technically difficult problems like how to have 99.999% uptime or how to built a mobile app that a user with bandwidth speeds in the bottom 1% can use. While these are interesting, they are not useful to me. I want to learn how Slack first built their chat application or how Substack allowed writers to host their newsletters at their own domain.

This newsletter is a continuation of my journey above and an extension of my curiosity in how early products were built.

Why “Monolith”?

I was enamored with microservices early in my career. I thought monoliths were a dated way to build software. It took me years to realize how wrong I was. I chose the name “Monolith” because it is emblematic of the deep misunderstanding I had about building at startups.