Build vs buy: when custom software is actually worth it
We build custom software for a living. So the honest thing to say up front is a little awkward: most of the time, when a founder asks us to build them something, part of our answer is "buy that part instead." Over the years we have joined enough products in the middle of development to see the same mistake again and again, and it is almost never that someone bought a tool they should have built. It is that someone built a thing they should have bought, and now they are paying to keep it running. Here is the way we think about the choice, in four questions: is this the part that makes you different, does a good tool already exist, will getting it exactly right change the outcome, and can you afford to own it forever.
The word "own" is the one that confuses people, so start there.
When should you build custom software instead of buying a tool?
Build custom only for the part of your product that makes you different from competitors, where no existing tool fits and getting it right changes your business outcome. For everything else, such as billing, login, or email, buy a proven tool, since building those parts yourself adds cost and risk without adding value.
| Buy | Build | |
|---|---|---|
| Best for | Solved problems: billing, login, email, analytics | The part that makes you different |
| Upfront cost | Lower | Higher |
| Ongoing cost | Spread across every customer by the vendor | Falls entirely on your team, forever |
| Who carries the risk | The vendor, who has solved it before | You, including bugs, security, and upgrades |
| Speed to launch | Fast | Slower |
Buying means renting. Building means owning every day.
The usual way people frame this is that buying is a monthly fee and building is a one-time cost you then own. That framing is backwards. When you buy, you rent the tool and the vendor keeps it working, fixes the security weaknesses, and releases new features with no work from you. When you build, you do not own the software once. You own it every single day after launch: the bugs, the upgrades, the security patches, the person who has to be on call when it breaks at 2 a.m.
In our work, the first version is rarely what surprises teams. It is the second year. A login system you built looks cheap the week it is released and expensive the week a new attack makes the news and you are the one who has to respond. A billing system you built is fine until tax rules change in a country you just expanded into, and now that is your engineers' problem instead of a vendor's. None of that shows up in the build estimate. All of it is paid for with your own team's time.
So the real question is not "what does it cost to build this." It is "can we afford to keep this running for as long as we need it." For most common parts of a product, the honest answer is no, or at least not well.
Build only the part that makes you different
Here is the rule we keep coming back to. Build the part of your product that is the reason customers choose you. Buy everything else.
Almost every product is made of two kinds of work. There is the part that is genuinely yours: the pricing engine that is your whole advantage, the matching logic in your marketplace, the model that makes your feature impress users. And there is the part that every product needs and none of your customers will ever praise you for: sending email, logging users in, taking payments, storing files, showing a chart. The first kind is worth building because getting it right changes your business. The second kind is a solved problem, and building it yourself does not make you special. It just gives you more code to maintain and no benefit in return.
This split is often more uneven than people expect. In machine learning systems, researchers at Google pointed out that the actual model, the clever part everyone talks about, is only a tiny fraction of a real system. The rest is supporting work: data pipelines, serving, monitoring, all the unexciting work around the model. The same pattern holds for products in general. The part that truly makes you different is usually small. When you try to build all of it yourself, you spend most of your effort on the supporting work that a tool would have given you for free, and you leave too little time for the one part that was actually worth your team's time.
So when someone asks us to build a full product, the first thing we do is separate the two. What here is yours, and what here is just the basics every product needs. Then we build the first and buy the second.
Bigger builds are where the most money is lost
There is a second reason to keep the custom part small, and it is not about focus. It is about risk.
Large custom software projects have a poor history of results, and the numbers are clear. In a study of more than 5,400 projects, McKinsey and the University of Oxford found that large IT projects (ones with initial budgets above 15 million dollars) ran on average 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. That last figure matters most. The average large custom build does not just cost more than planned. It delivers a little more than half the value it promised.
The reason is size itself. A big build has more parts, more assumptions that depend on each other, more places for a wrong guess in month one to quietly break something in month nine. Every part you decide to build custom is another part that can go over budget, another part someone has to maintain, another thing that must work before your product works. Buying a part does not just save build time. It moves that whole part of the risk away from you and onto a vendor who has already solved it many times.
This is why "buy most of it" is not the timid choice. It is the lower-risk choice. You reduce the custom work to the part that has to be yours, and you refuse to take risks on the parts that do not.
When you do build, build it small
None of this means custom is a mistake. Sometimes the differentiating part is real and worth every hour. When that is the case, the way you build matters as much as the decision to build.
The strongest engineering teams do not build the whole thing and reveal it at the end. They release in small, frequent steps. The research behind DORA, the long-running study of how software teams actually perform, keeps finding the same thing: teams that release in small increments have lower failure rates than teams that release rarely in big batches. A small piece that goes wrong is easy to see and easy to fix. A giant release that goes wrong hides the problem inside a hundred changes at once.
So when we build the custom core for a client, we scope it down and release it in pieces. Get the narrow thing that is truly theirs working first, put it in front of real users, and learn before adding more. This is how you keep even a genuine custom build from turning into one of those 56-percent-of-the-value projects. You do not lower the risk of a big build by planning harder. You lower it by making the build smaller.
The honest way to decide
Put it together and the decision gets simple, even if it is not always comfortable. Run each part of your product through the four questions from the top. Is this the part that makes us different from everyone else. Does a good, proven tool already exist for it. Will getting it exactly right actually change our outcome. Can we afford to own and maintain it for as long as we need it. Build only where the honest answers point to custom on all four. Buy everywhere else, and do not feel bad about it.
The problem is that building always feels like progress and buying always feels like accepting less. It is the opposite. Every hour your engineers spend rebuilding a solved problem is an hour they are not spending on the one thing only you can build. Buying the common parts is how you free your best people to work on the part that matters. If you want a deeper version of this same idea, we wrote about it in knowing what to build, and the same instinct shows up when you choose who builds it with you, which we covered in software development partner vs. vendor.
When custom is the right choice, that is what we do. We build the differentiating core and we build it small, with progress you can see, whether that is a focused piece of custom software development or a full product build where we buy the common tools and build only what is yours. And when custom is the wrong choice, we say so, even though it means less for us to build.
Build the part that is yours. Buy the part that is everyone's. Almost every expensive mistake we see is a team that did the opposite.
What cheaper building does to this decision
This calculation favoured buying for years: buying was usually right because building was slow and expensive, and a custom build had to meet a high standard to be worth it.
AI code generation lowers that standard. Work that was obviously not worth a custom build, an internal tool, a narrow workflow nobody sells a product for, is now worth building in cases where it plainly was not before.
Ownership stays the same. Anything you build is yours to run, monitor, secure, and change for as long as you use it, and that cost is unchanged. So the rule allows more building than before without reversing: build what makes you different, buy the rest, and remember that the second question is not what it costs to build but what it costs to keep.
Sources
- McKinsey and University of Oxford (2012), "Delivering large-scale IT projects on time, on budget, and on value": https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
- DORA, Accelerate State of DevOps research: https://dora.dev/research/
- Sculley et al. (2015), "Hidden Technical Debt in Machine Learning Systems," NeurIPS: https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems
Related guide: Custom software: build vs buy.
