Total cost of ownership is one of those concepts that sounds obvious but gets skipped frequently. Most people already understand it intuitively when it comes to something like a vehicle. A Toyota might cost more upfront and the parts might be pricier, but if the Ford breaks down twice as often, the cheaper purchase price doesn’t mean much over five years of ownership. People think about maintenance, reliability, resale value.
When it comes to technical decisions, that same thinking often goes out the window. A team will compare two price tags, pick the lower one, and stop there, but the price tag only tells you what something costs to buy, not what it costs to own.
The Database Example
Here’s a simple example I’ve used before to illustrate this. Say you need a MariaDB database on AWS. You need 100 GB of storage, 4 vCPUs, and 16 GiB of memory. You have two options.
Option A: run MariaDB yourself on two EC2 instances (a primary and a standby). Two m5.xlarge instances in us-east-1 run about $280 a month.
Option B: use RDS Multi-AZ, where Amazon manages the database for you. That same spec on RDS comes in around $520 a month.
On sticker price, EC2 wins by $240 a month. Obvious choice, right?
But with RDS, Amazon handles automated backups, replication, automatic failover, OS patching, and MariaDB updates. On EC2, your team handles all of that.
So what does that actually cost? Let’s say the average salary plus benefits for an SRE is around $170k, which works out to roughly $82 an hour. If your SRE spends 2 hours a month on routine maintenance of the EC2 setup, plus another hour or two on unplanned work when things break, you’re looking at 3-4 hours a month of engineering time. That’s $246-$328 a month in labor, which brings your EC2 total cost to $526-$608.
The $240 a month in savings just disappeared, and you’re still carrying the risk and on-call burden on top of it. When your self-managed database has a failover event at 2 AM, someone has to wake up and deal with it. RDS handles that automatically. Regular 2 AM pages contribute to burnout, and burnout contributes to turnover. Replacing an SRE costs a lot more than $82 an hour.
The Pattern
The database example is simple, but the pattern behind it shows up everywhere.
A team evaluates a SaaS tool that costs $2,000 a month versus building something in-house. The in-house option looks cheaper because the developers are already on salary. But the three months of development time, the ongoing maintenance, the on-call burden, and the opportunity cost of those developers not working on the product all factor into what it actually costs.
The question isn’t “can we build this.” The question is “should we own this.”
A company picks a cheaper vendor because the per-unit cost is lower. But the integration work, the support quality, and the time the team spends working around limitations that the more expensive vendor had already solved are all part of the real cost.
Or someone hires a cheaper contractor because the hourly rate is lower. But the ramp-up time, the rework, and the hours a senior engineer spends reviewing and correcting the output are all part of what that contractor actually costs.
The pattern is the same in every case. The sticker price got compared. The total cost of ownership did not.
Build vs Buy
This is especially common in build-vs-buy decisions. Engineers love to build. There’s a gravitational pull toward building your own solution because it feels like the cheaper, more flexible option, and because building things is more interesting than evaluating vendors.
But building something means owning it forever. It means maintaining it when the person who built it leaves. It means debugging it at 3 AM when it breaks in a way nobody anticipated. It means every hour spent maintaining your custom solution is an hour not spent on the thing your company actually sells.
Sometimes building is the right call. When the thing you need is core to your product, when nothing on the market fits, when the cost of a vendor dependency is genuinely higher than the cost of ownership. It’s worth being honest about whether that’s actually the case though.
The question isn’t “can we build this.” The answer to that is almost always yes. The question is “should we own this.” The first is a sticker price question. The second is the total cost of ownership question.