When building at a startup, sometimes you envision an ideal solution first, making it hard to see anything else. “Do the low-tech thing first” is the rebuttal to this. It’s a simple team value that challenges the sneaky and wasteful instinct to over-engineer, over-analyze, over-anything-but-ship.
Primarily, the expression means: give yourself permission to be simple and unsophisticated, when doing so works, and when the fancier option isn’t obviously justified right now.
You can call it a spiritual cousin to “Do things that don’t scale” and to Fred Brooks’s “Plan to throw one away”. I reach for this value a lot, because situations where it is needed come up a lot.
Builders, especially those motivated by a strong sense of quality in their work, will often have a hard time resisting a robust and complete solution to a problem. But such options are frequently an order of magnitude more expensive than their hacky alternatives. This means our ideal must be justified by the problem at hand. And if not, the low-tech option should prevail.
What do “low-tech” solutions look like? In my experience, they can be ugly, unglamorous, and eventually brittle. Exactly the kinds of things you’d be otherwise embarrassed to propose to a colleague. Here’s an example:
We needed to report metrics on one stage of our hiring pipeline, every week, for a quarter. One option was to hook into the API of the hiring tool, shunt the data off to Grafana, and enjoy the fruits of automation. We estimated 6 hours of dev time, and hopefully no maintenance.
Instead, someone volunteered to visually scrape the hiring tool, weekly, appending the numbers into a spreadsheet. We timed it as taking 5 minutes every Monday, 1 hour in total.
This was gross. It would get old after a while. And it completely met our needs.
While you can always go back and reach for the fancier option later, you can never recoup sunk costs. A startup’s ability to move fast in areas core to the product should be one of its strongest advantages against the competition. These hacks buy you more of that time.
Clearly, if you can justify the high-tech option, you should go for it.
But if you see an opportunity to try a vastly lower-tech thing first, at much cheaper cost, don’t agonize over it. Declare it as such, and set a shelf life for outgrowing it. It’s exactly this shelf life which should help you feel pragmatic, and not unsophisticated, about the decision. “If we get to <X>, we’ll build that other thing”, you say. “But we’re not there yet.”
Kind thanks to William Myers for reviewing a draft of this post.