The Opportunity Cost of an Engineer’s Time: Do It Yourself or Buy It Off the Shelf

The decision between building in-house or buying off-the-shelf is often debated using a comparison that’s flawed from the start: on one side are the monthly service bills, and on the other is zero—because building in-house “only costs the team’s time.” That time is actually the most expensive item on the list. It just doesn’t show up anywhere because no one sends a bill for it.

This article attempts to do something simple: put a price on that period, build a five-year model with clearly stated assumptions, and then see what the numbers tell us. Every model is wrong in some way, but a model that’s wrong—and that we can see is wrong—is still better than a flawed intuition that we can’t verify.

First of all, how much does an engineer charge per hour?

It’s not just salary divided by hours. The true cost of an engineer’s hour includes salary, insurance, equipment, workspace, software, recruitment, management—and most importantly, time not spent writing code: meetings, interviews, vacation time, reading documentation, and waiting for reviews. The standard conversion is 1.5 to 2 times the gross salary, divided by the actual number of hours worked, not the number of hours present.

The exact figures vary by location, and I won’t guess for you. From here on out, everything is calculated in engineer-hours. You’ll need to multiply that by your own unit rate in the final step.

A Five-Year Plan

Suppose there is a system for which the initial estimate is “two weeks to complete”—80 hours. Compare this to an off-the-shelf service that performs the same task. These are the assumptions:

The figure of 360 hours wasn’t made up to undermine the do-it-yourself option; the following section will break it down into individual items. As for the 72 hours of maintenance per year, that represents 20% of the initial effort—a common figure for active in-house software.

Break-even point, and how sensitive it is

The difference between the two lines is 496 hours over 60 months, or about 8 engineer-hours per month. That is the break-even price: any service that costs less than 8 engineer-hours per month is cheaper to purchase than to do in-house, based on the assumptions outlined above.

For most popular infrastructure tools, 8 engineer-hours per month is a generous allocation. That’s why the intuition that “writing it yourself is cheaper” is so often wrong.

But a model is only reliable if you know where it breaks down. Let’s try changing each assumption one by one:

The last line is the most important. The model above assumes a fixed rental price. Many services are billed based on usage, and the price you agree to in the first year isn’t the same as the price you’ll pay in the fourth year.

Why did "two weeks" turn into 360 hours?

The estimate of "two weeks to go" is almost always accurate for a working version: one that runs as a demo, follows the correct flow, and has clean data. It's not wrong—it answers a different question than the one you're asking.

The discrepancy lies in the things no one mentions during the estimation meeting: dirty data, users clicking buttons twice, malicious actors attempting to exploit the system, access controls, logs detailed enough to figure out what happened at 3 a.m., and documentation that would make a second person dare to touch it. None of that is interesting, and that’s exactly why none of it was included in the estimate.

A rough but workable fix: multiply the initial estimate by three. This isn’t because the engineer’s estimate was poor, but because the question was systematically misunderstood.

The four model components above do not include

Opportunity cost. Nine months of building something yourself means nine months without that feature being released. If what you’re building is blocking a source of revenue, the true cost isn’t 360 hours—it’s 360 hours plus nine months of lost revenue.

Coordination costs. Custom code requires review, someone to monitor it, attendance at architecture meetings, and someone to remember it exists when the library is upgraded. These costs increase with the number of people on the team, not with the number of lines of code.

Security and compliance. A custom-built authentication system is one that you have to patch yourself. If the work involves any standards, you’ll have to demonstrate compliance yourself as well.

Exit costs. This factor applies to both sides and is often the most overlooked. How much does it cost to leave an off-the-shelf service? How much does it cost to abandon a custom-built system that’s deeply integrated into ten other systems? This question is so important that it deserves its own section.

Decision-making framework: two axes, not one

A common piece of advice is to ask, “Is this what makes customers choose us?” That’s a good question, but it’s only half the story. The other half is: if this decision turns out to be wrong three years from now, how much will it cost to undo it?

The most dangerous box is the top-right corner: things that don’t make a difference but lock you in very tightly. Payment, authentication, data storage. It’s very easy to shrug it off and buy them because “they’re not core components,” only to discover three years later that half your system speaks the vendor’s language and you can’t get rid of them. In this case, buying is often the right choice—but you have to put your own interface layer in the middle right from the start, while it’s still cheap.

When "buying off the shelf" is the wrong decision

Four common types of failure, ranked by frequency:

• The price changes once you’ve put down roots. You don’t negotiate from the position of someone who can walk away.
• Scale flips the equation. The pricing model for the service is designed for the average user. Once you exceed that level, you’re paying for a convenience you no longer need.
• The provider changes direction or disappears. The product gets acquired, discontinued, or shifts to a different customer base.
• What you need gradually drifts away from what they’re selling. Then you write code to work around the product—and end up losing the initial benefit.

When you do it right yourself, even if it’s not the core

Two public examples, both on a scale where the calculation is reversed.

Dropbox migrated most of its user data from Amazon S3 to its self-built infrastructure between 2015 and 2016. Its IPO filing reported savings of approximately $75 million over the following two years. Storage isn’t why customers choose Dropbox—but at that scale, a difference of a few percent per terabyte adds up to a figure greater than the cost of building a team.

37signals moved away from the cloud in 2022–2023 and reported savings of approximately two million dollars per year. They also specified the conditions: fairly stable traffic, a small but skilled operations team, and no need for sudden scalability.

The common thread isn’t that “building it yourself is cheaper.” The common thread is that both had explored the option of buying a ready-made home long enough to know exactly what they needed before they built. That’s the right order of events, and it’s the opposite of how most decisions to build a home are made—that is, building first and figuring it out later.

The third option that binary questions overlook

• Self-hosted open source. No need to buy it, and no need to write it. You have full control and aren’t locked in—but in return, you have to handle the operation yourself. This is often the missing piece that the “buy or build” debate overlooks.
• Buy and wrap it. Use the service, but access it only through your own interface layer. It takes a few extra days upfront, and turns the “exit cost” from a project into a week’s worth of work.
• Buy first, build later. Use off-the-shelf solutions until you clearly understand your actual needs, then decide whether to build. This is exactly what Dropbox and 37signals did.
• Build a thin layer on top of an off-the-shelf solution. The part that makes the difference is yours; let others handle the boring stuff.

Team Size Changes the Equation

For a solo developer, opportunity cost is virtually everything: every hour spent on the supporting system is an hour not spent on the product, and there’s no one else to handle maintenance. The threshold for making a purchase should be much lower than it might seem.

With a team of a few dozen people, coordination costs and the risk of staff turnover become apparent: a system developed in-house that only one person understands is a debt with an expiration date.

For large organizations, scale begins to turn everything upside down—and only at that point does it make sense to set up an entire team to maintain the internal system.

Make it a reversible decision

Most "buy-or-build" decisions are made once and then never revisited, even though all the assumptions behind them are bound to change. Here are three inexpensive ways to fix that:

• Record your assumptions at the time of the decision—how many hours you estimate, what the rental price is, and how many years you expect it to last. A single paragraph is sufficient.
• Track actual maintenance hours. If you don’t track them, you’ll never know whether that 20% figure is accurate for you.
• Schedule a review after 12 months. Not to make changes, but to compare your assumptions with reality—that’s the only way to make your next estimate better than this one.

In summary

Doing it yourself isn’t free; it just doesn’t come with an invoice. When converted to engineer-hours and spread over five years, the break-even rental rate is often much higher than one might intuitively expect—in the model above, it’s about 8 engineer-hours per month.

But that number isn’t as important as the habits that lead to it. Put a price on time, clearly state your assumptions, add a cost-of-withdrawal axis alongside the variance axis, and set a date for a review. The decision may still be wrong—but it will be wrong in a way you can detect, rather than silently becoming more expensive over the course of five years.