Category: ideas

Not so long ago the internet consisted of websites running on beige boxes under people’s desks and in storage closets. You’d back the drive up every once in a while if you were smart; if not you still got lucky the vast majority of the time. And if the web daemon crashed or the kernel panicked you’d restart it and life went on.

Since that magical period in the history of the internet, there has been so many cool new whiz bang ways to automate and flex and scale and recover. Load balancing, virtualization, orchestration, and other tools are all freely available to use in your personal and professional projects, offering levels flexibility and resiliency previously unheard of outside of enterprise scenarios.

But despite what you may think, you do not need whiz bang, fully automated, five-nines-grade infrastructure backing your project. You don’t need multi-region, much less multi-cloud. It adds complexity and costs in both time and resources at a stage when they serve no purpose and only slow you down.

Kelly Johnson’s 14 Rules for teams at Lockheed’s Skunkworks epitomized his “keep it simple stupid” approach . There was more than enough complexity in what their team was trying to accomplish; adding needless complexity was wasteful and potentially dangerous.

David Futcher nails it in his 2019 Medium article “You Don’t Need All That Complex/Expensive/Distracting Infrastructure“:

Your users to don’t care how your code gets onto your server. 99.9% of the time they don’t care about your fancy high availability setup either. Obviously if you’re FAANG-level or some established site where that 0.1% downtime translates into vast quantities of cash disappearing from your books, this stuff is all great. You have the funds to do things “right”. Your fancy zero-click continuous deployment system saves you thousands/millions a year. But at indie maker, “Hey look at this cool thing I built … please, please someone look at it (and upvote it on Product Hunt too, thx)” scale — the scale of almost every single site on the net — that 0.1% is vanishingly insignificant.

Or as your parent likely told you growing up: “Just because you can doesn’t mean you should.”

David went on to remind us how “Engineers get sidetracked by things that make engineers excited, not that solve real problems for users.” I know I’ve fallen into that trap plenty of times. Focusing on the outcome rather than obsessing over the tools is crucial to maximizing velocity. Build only what you need to achieve the goal, no more, no less.

So go ahead and run it on a single EC2 instance. I do. Completely meets my needs. If I get slashdotted (remember when that was a thing?) I’ll wear it like a badge of honor, just like we used to.