Almost three years ago to the day I left my job at (then) Facebook and started at what was then a one-year old company with five total employees: the three founders, a designer, and me.
And if I have one piece of advice for myself from those three years it’s this: the learning curve at an early-stage startup is gentler than you think.
Don’t get me wrong, I’m not claiming there’s no curve nor that it’s easy. Rather — as was the case for me — if you’ve never worked at a startup before, you may be over-estimating how much you need to learn and how quickly.
The nightmare
If I’m to be honest, before I left Facebook, the concept of joining such a small team (three engineers) was simultaneously exciting and nerve-wracking. Learning was the reason I left Facebook for a startup; I wanted more of it, faster. But on the other hand, I knew this would involve intentionally getting in over my head.
At the time I had this technical nightmare: a problem would suddenly appear — a database migration gone wrong — and that we’d lack the expertise to solve it. Coming from big tech, the details of our database or cloud infra details had always been abstracted away from me, but now I had no one to support me, no infra team of experts at my back.
In this nightmare I’d watch the company burn to the ground overnight; all of this would have been for naught.
The reality
The years have helped me realize that these fears were misplaced; I vastly misunderstood a few things.
Here were two:
Just how hard getting users is
The difference between launch quality at an early-stage startup and at a company with billions of users
At big tech, launching a product can feel more like flipping a scary switch: you might release a product and, even gated behind an A/B test, have hundreds of thousands of users trying it the next day.
In this scenario, there are a number of fears. You have enough users to create interesting load problems. Users have high expectations based on your established reputation. Do all of the happy paths and edge-cases work? Is the product clear enough?
On the other hand, in the earliest days of Graphite, we had tens of users. Tens. When we’d launch features, we’d be happy to capture a few users. I had worried about scaling issues before I joined; now I prayed of them — it’d be a perverse mark of success.
A different customer
It wasn't just the number of users that I hadn't been prepared for; it was also the type.
When I look back now on screenshots of our product back then, it was amply clear that this was not a tool refined by years of development. We weren't fooling anyone. But all of our users knew what they were signing up for — and enjoyed it. These users were the earliest of the early adopters. They were happy to hop on calls with us and help us improve our product, taking the journey along with us.
When we did make mistakes, it was also far easier to clean them up. In addition to looking at a crash log, we would also call the user. Did you notice anything else interesting before the crash? Do you have any other feedback?
And with less code and data in general, migrations to undo technical mistakes we had made were also shockingly simple. Before I joined the company, the founders chose to migrate our codebase from Django to TypeScript. (I’m eternally grateful.)
Migration time: two weeks.
Before I joined, part of my fear stemmed from thinking of users as anonymous folks who would judge us for every small mistake and flame us at the drop of a hat.
What I found instead was that building in this environment was more akin to hacking something together for your friends. Our users were rooting for us.
Database issues
Eventually one day, we were faced with a mystery: what had previously been cheap Postgres queries were becoming very expensive — with no change in volume of calls or database size. The query plans looked sensical; things were just slower and slower by the day and users were really starting to take note and voice their displeasure. It was my fear realized: here I was, under the gun, needing to build up real-time expertise.
After countless late nights, I finally found the issue. It was a leftover replication slot that was blocking autovacuum. I came in on a Sunday and ran pg_repack on the problematic tables and was elated to see DB CPU plummet.
We and I survived.
The difference was that I had expected this to be my day one. Instead, this was nearly two years in — two years of slowly building expertise over time rather than a sudden crash course all at once.
I’ll stress it again to be extremely clear: the work is hard and only gets more difficult the longer the company stays alive. I can’t stress how hard the art of finding users and later getting them to pay for your product is.
The technical parts though? As long as come with an appetite to learn — you’re probably more ready thank you think.
And if you were one of our earliest users (I still remember when I'd come to work every day and check the dashboard that would show all ten of our users), I'm eternally grateful. Thank you for helping us and sticking with us.
