I recently re-read Paul Graham’s essay entitled “Do Things That Don’t Scale”. In it, he explains that early on in the development of a company or product, you should do things that won’t scale because they’ll be what get you to the point that you actually will have to scale. If you don’t do the simpler, sometimes manual work upfront, you may not capture the market before a competitor does because you spent too much time building the “scalable solution.”
I’ve been thinking about that essay a lot lately. I’m fortunate to be part of a team that is building a new product within my company, and we’re operating similarly to a startup. We run down our own sales leads, do our own tech support directly with customers, and so on. We’ve learned a lot doing it - it’s been a great experience. These experiences have also helped me hone my sense of what we have to build versus want to build. If a customer hasn’t asked for it and it’s not immediately impeding our ability to meet our short-to-midterm objectives, it’s probably not important enough to prioritise right now. We simply can’t do everything so filtering early and often helps drive that focus. That’s not to say we have no long term view, it’s just a driving part of our calculus.
As I’ve reflected on pg’s essay and what I’ve learned from work, I had a realisation. The reason that a lot of my personal projects have fizzled out in the last few years has been because I’ve spent too much time in analysis paralysis trying to figure out what design decisions will scale. But let’s be honest, the toy dictionary API I wrote in whatever language is the flavour of the week isn’t going to be a money maker. No one will rely on it and so why does it need to scale to 200k requests per second?
Since having that realisation, I have resolved to build small things. Things that are fun or help me learn something new. Maybe one of those will turn into a big new idea, but probably not because that was never the point to begin with.
PS: If you’re curious what sorts of small things I’m building, they’ll probably show up at api.zacbrown.org. The code for that site can be found at:
—–Posted on: 2019-01-12