Build vs. buy without lying to yourself

Build versus buy looks like a technical decision. It is really a decision about where your company's limited time and focus should go. Those are the two things you can never make more of, and every build-or-buy call spends one of them. Founders get it wrong in both directions, and the reason is almost always the same. They lie to themselves about the true cost of building. Sometimes they lie about the true cost of buying too. The framework does not matter much. The honesty does. This whole skill is just the willingness to price the real cost instead of the one you wish were true.

The real cost of building is never the build

When a team decides to build something, they estimate the build. How many weeks to write it. How many weeks to ship it. Then they call that the cost. It is the smallest part of the real cost. It is the visible tip of a much larger number, and the rest of the number does not show up until later.

Here is what they leave out. Once you build something, you own it. Forever. You maintain it. You fix it when it breaks, and it will break at the worst possible time, because that is when systems break. You update it when its dependencies change under it. You carry the knowledge of how it works in a few people's heads, and those heads walk out the door someday. The build was a one-time cost. The ownership is a permanent one. And ownership is the part that quietly eats teams alive, because it never shows up as a line item. It shows up as a slow, steady drag that no one can point at.

Picture the small internal build that looks harmless. A team needs a way to send transactional emails, so an engineer wires one up in an afternoon. It works. Everyone is happy. Then the provider changes an API and it breaks on a Friday. Then someone needs retry logic, so it grows. Then a new hire has to learn how it works before they can touch anything near it. Then it goes down during a launch and two engineers spend a day inside code no one has looked at in a year. None of that was in the estimate. The estimate was one afternoon. The real cost was one afternoon, plus a small tax every month for as long as the company exists.

A founder who says "we can build that in two weeks" is usually right about the two weeks and wrong about the two years. The two weeks is the part they can see. The two years is the part that costs the money.

The real cost of buying is dependence

Buying is not free either. The cost is just a different shape, and it hides in a different place.

When you build on someone else's product, you inherit their world. You inherit their limits. You inherit their pricing. You inherit their roadmap, which is not your roadmap and never will be. You inherit their outages. You move at the speed they allow, and not one step faster. That is the trade. You gave up ownership and you took on dependence, and dependence is a real risk. It just does not feel like one on the day you sign up, because on that day the vendor is doing exactly what you need.

The bill for dependence arrives later, and it arrives on their schedule, not yours. If they raise prices, you pay. You cannot easily leave, because leaving means rebuilding the thing you bought precisely so you would not have to build it. If they deprecate the feature you depend on, you scramble, on their timeline, to replace work you thought was done. If they go down, you go down, and you sit there refreshing a status page you do not control while your customers email you. If they get acquired and the new owner does not care about your use case, you find out you were never the customer they were building for.

Think about a company that builds its billing on a third-party platform. Fast to set up, one less thing to own, clearly the right call at the start. Two years later they want a pricing model the platform does not support. Now they are negotiating with a roadmap instead of writing code. The thing that saved them time at the start is the thing setting their pace at the end. That is dependence. It is not wrong to take it on. It is only wrong to take it on while pretending it is free.

The question that cuts through it

Stop asking "can we build it." You can build almost anything, given enough time. The answer to "can we" is almost always yes, which is exactly why it is a useless question. It tells you nothing about whether you should.

Ask "is this our core." That question sorts everything.

Build the things that are your actual differentiation. The things that are the reason your company exists and the reason it wins. The parts a customer would notice if they were worse. Buy the things that are necessary but not differentiating. The plumbing every company needs and no customer ever chose you for. Nobody signs up because your email delivery is yours instead of a vendor's. They sign up for the thing you do that no one else does.

Almost every painful build-versus-buy mistake comes from getting this exactly backwards. Teams build the commodity plumbing, because plumbing is a clean, well-defined problem and it is genuinely fun to solve. And they buy or neglect the core, because the core is messy and hard and never finished. So the team pours its best months into a beautiful internal tool for something a vendor would have handled for a monthly fee, and hands the actual differentiation to an off-the-shelf product that makes it average. They own the wrong thing and rent the wrong thing, and both mistakes came from choosing by what was interesting instead of what was core.

The discipline is the reverse of the instinct. Be willing to own the difficult, central thing that makes you you, even though it is hard and it never ends. Refuse to own the generic infrastructure a vendor does better and cheaper than you ever will, even though it looks easy and building it would feel good.

The trap of "we can build it better"

Engineers love this one. So do founders who used to be engineers, which is most of them. You look at a paid tool you are about to buy, and you think, this is not even that hard. We could build a better version of this in a month. And the frustrating part is that you are often right. You probably could.

That is the wrong question. The question is never whether you can build a better version. The question is whether building a better version of something that is not your core is the best possible use of the one thing you cannot buy more of. Your team's time. Your team's focus. There is a fixed amount of both, and every hour spent on a better internal tool is an hour not spent on the thing customers actually pay for.

Run the honest math. A slightly better internal version cost you three months. Fine. What did those three months not get built? If the answer is a real improvement to the thing that is actually your differentiation, you made a bad trade. You spent your rarest resource making a commodity marginally nicer while the thing that wins customers sat still. Marginally better plumbing does not win. It never has.

Name the real pull, because the math alone does not explain why smart teams keep doing this. It is ego. Building the better version feels like proving something. Paying a vendor for a solved problem feels like admitting they beat you to it. That feeling is the trap. The discipline is to let a vendor win the commodity fight without needing to prove you could have won it, so you can save the fight for where it counts.

The trap of "buying is always faster"

The opposite trap is just as expensive, and it hides better, because it wears the costume of being the sensible, grown-up choice. The trap is assuming buying is always the quick, safe path. It is quick. It is not always safe.

Sometimes the thing you need is so central to your product that buying it means building your whole company around a compromise. The bought solution does eighty percent of what you need, fast, on day one. That feels like a win. But the twenty percent it does not do is the twenty percent that was supposed to make you different. And you cannot add it, because you do not own the thing. So your core experience quietly settles at average, shaped by what the vendor allows.

That is how the speed you gained up front turns into a ceiling you cannot break through later. Early on, buying looked like a shortcut. You shipped faster than the team that chose to build. Then you both grew, and they kept climbing while you hit the top of what your vendor supports. Now the only way up is to rip out the bought solution and build the thing you skipped, except now you have to do it with live customers depending on the old behavior, which is far harder than building it would have been at the start. The shortcut was real. It just led to a wall.

For the things that are genuinely your differentiation, the slow path of building is often the only one that gets you somewhere a competitor cannot easily follow. Anyone can buy what you bought. That is the whole problem with buying your core. The moat is the part you were willing to build when it was slow and hard, precisely because it was slow and hard, and your competitor was not willing to do it either.

What Stack Learner actually built, and what it did not

When I built Stack Learner, the ed-tech platform I founded and ran for roughly a decade, we built our own data platform, our own content management system, and our own customer tooling. Write that down as a list and it looks like the classic build-it-all mistake. A small team owning three heavy internal systems. It reads like a cautionary tale.

It was not, and the reason is the whole point of this article. Stack Learner is a data-driven business at its core. How we understood learners, how we tracked what worked, how we shaped the product around what the data told us: that was the differentiation. That was the reason the thing worked at all. So the data platform was not plumbing. It was the product behind the product. Owning it was not overreach. Owning it was the point. If we had bought a generic version, we would have built the whole company around someone else's idea of what our data could do, which is the exact ceiling I just described. We built it because it was the one thing we could not afford to rent.

But not everything got built. This is the part people skip when they hear "they built their own data platform" and decide we were a team that built everything. Plenty of the surrounding infrastructure we bought, used, and never thought about again. Hosting, email, payments, the ordinary machinery every company runs on. We did not agonize over those. We did not try to build a better version to prove we could. We paid for them, wired them in, and spent zero further thought, because none of it was the reason anyone came to Stack Learner. Every hour we did not spend reinventing plumbing was an hour we spent on the data platform that actually mattered.

So the discipline was never "build" as a rule. It was never "buy" as a rule either. Rules are what you reach for when you do not want to do the honest work of deciding. The discipline was knowing, honestly, which parts were the reason the company existed and which parts were just necessary. Build the first kind. Rent the second kind. Do not confuse them, and do not let what is fun to build fool you into thinking it is core.

How to run the decision honestly

Most of this comes down to catching yourself in the lie, whichever direction it runs. A few checks make that easier.

• Estimate the ownership, not the build
• Name the dependence out loud before you buy
• Sort by core, not by what is fun
• Watch for the word "better" when the thing is not core
• Watch for the word "faster" when the thing is core

Estimate the ownership, not the build. Before you decide to build, do not ask how long it takes to ship. Ask who maintains this in two years, and what it costs when it breaks, and what happens when the person who wrote it leaves. If those answers are fine, build. If they scare you, that fear is the real cost showing itself early, which is the one time it is cheap.

Name the dependence out loud before you buy. Before you decide to buy, say the sentence plainly. We are betting this vendor keeps their prices, keeps this feature, and stays up. If that bet is fine for a piece of plumbing, take it and move on. If that bet is on the thing that makes you different, you just described building your company on someone else's decisions.

Sort by core, not by what is fun. When you feel the pull to build something, check whether you are drawn to it because it is central or because it is a clean, satisfying problem. Those feel identical from the inside. They are opposite answers. The interesting commodity is the single most common thing teams wrongly choose to own.

The last two are the two traps in pocket form. When you catch yourself saying you could build it better, check whether the thing is core, because "better" only matters where it is. When you catch yourself saying buying is faster, check the same thing, because faster is a trap exactly where the thing is core. The word you use gives away which lie you are telling.

The whole skill is the honesty

None of this is really about a framework. Frameworks are easy. You can find ten of them, and they will all tell you roughly the same thing, and none of them will save you, because the hard part was never the sorting. The hard part is being honest about which bucket a thing actually goes in when you badly want it in the other one.

You want to build the fun commodity, so you tell yourself it is core. You want the quick win, so you tell yourself the compromise will not matter. You want to prove you are the better engineer, so you tell yourself three months on a solved problem is a good trade. Every wrong build-or-buy decision I have seen started with a true fact and a story wrapped around it to reach the answer someone already wanted. The framework was fine. The person using it was lying to themselves.

So the question is not "can we build it." You can. The question is whether this is the thing you should own forever, or the thing you should rent and forget. Answer that one without flattering yourself, and the decision usually makes itself.

Own the thing that makes you different. Rent the thing that makes you the same as everyone else. The only hard part is admitting which is which.