It’s a well-known truism in software engineering that you shouldn’t ask an engineer to build and maintain software that only saves you a few hundred bucks a month, because engineers cost more than a few hundred bucks a month.
You can distill this down into a few easy calls that apply in almost all situations:
- No, don’t code your own database from scratch, use an existing open source or commercial one instead.
- No, don’t self-host a database on your own hardware, if you can use an equivalent managed cloud service instead.
- No, definitely don’t build and self-host your own database on your own hardware.
There are a few nuances and exceptions to this rule for small startups:
At the very earliest “founders and 1-2 employees” phase, it can make sense to avoid expensive managed services, if you can save precious cash for something else. This is because there can often be a marginal 9th (or 10th…or 11th) hour in a working day that doesn’t actually displace anything else — in other words, build some sweat equity in lieu of spending cash, which might work out if it lets you delay or skip fundraising, and keep more of the pie for yourself. If you’re a small founding team, that might be a reasonable trade to bet on (the benefits get too diffuse once headcount exceeds a dozen or two). This happens to be important for an ancillary reason, namely, it can be a sign that early folks are resourceful enough to not need money to solve every problem. I cringe at co-founder pairs spending hundreds a month on “time tracking” and “project management” software when Google Sheets and Trello is a thing.
For an early stage company with more than a handful of employees, sometimes DIY or self-hosting can still make sense even if the math doesn’t appear to pan out. This may be because 1) at this moment there isn’t anything else that would be more valuable for that engineer to build, and/or 2) it doesn’t represent incremental cash outflow – you’re already paying an engineer, so that salary commitment is a sunk cost; they should do whatever work results in the most cash savings or increased revenue — even if individual projects don’t always cover the cost of the employee’s salary. In other words, it might be smarter to avoid the option that definitely increases cash burn (buying a new service).
Additional build vs buy factors to consider include a few things that are easy to get wrong, and sometimes effectively unknowable:
- “The innocent hack that ends up being a mission-critical beast”: If something custom but innocuous gets turned into this irreplaceable mission-critical thing, then it becomes a chain around your neck forever and gets harder to rip out as you grow more dependent on it. And you’ll have this unique snowflake with its own documentation, training and support cost that you can’t hire externally for. It becomes debt in the classic sense, in that it commits future resources to its care and feeding.
- Feature set and customization: It can be tempting to either “build your own” (or fork something, which is almost the same) rather than using just things off the shelf because “nothing else suits our use case.” This almost always causes operational issues later , and is generally symptomatic of some other issue — either the team is insufficiently imaginative/adaptable, has adopted unusually broken workflows, or is just plain unskilled enough to actually read existing code and documentation. Some teams do truly need to build something custom for certain business processes, but this should be very rare early on.
So, a couple takeaways.
Frugality as a value only moves in one direction.
Have an exit strategy if you DIY, since you usually don’t want to be trapped maintaining and extending a homebrew solution forever that doesn’t create a competitive strength for you.
If you keep saying “nothing out there suits my use case” in every domain you encounter, the odds are you’re doing it wrong.
 I always like to say that forking is easy, merging is hard. This happens to be true in a number of domains (like processes), not just code libraries.