The short version: buy anything that is a commodity and not your differentiator, build the thing that actually makes you different or that nothing on the market fits, and be honest that both choices carry hidden costs you will not see in the first month. Most build versus buy mistakes come from getting the differentiator question wrong, then defending the mistake with sunk cost.
Buy the commodity
If a capability is undifferentiated, buy it. Authentication, payments, email delivery, error tracking, analytics, log aggregation, most of your internal tooling. Nobody has ever won a customer because their in house authentication was marginally nicer than an off the shelf provider. These are solved problems where a vendor has spent years on edge cases you have not even imagined, and where reinventing the wheel buys you nothing but maintenance.
The test is simple. Ask whether a customer would pay you more, or choose you over a rival, because you built this yourself. If the honest answer is no, you are looking at a commodity, and every hour spent building it is an hour stolen from the thing that does win customers. Engineers love building infrastructure because it is satisfying and legible. That instinct is exactly what you must resist for commodity work.
Build the differentiator
Build the thing that is the reason your business exists. If your edge is a pricing engine, a matching algorithm, a particular workflow that your customers cannot get anywhere else, then that is not a candidate for a vendor. Buying your differentiator means renting your competitive advantage from someone who will sell the same thing to your rivals tomorrow.
There is a second, quieter reason to build: when nothing on the market actually fits. Sometimes a category of tool exists, but every option assumes a workflow that is wrong for you, and bending your business to fit the tool would cost more than building. That is a legitimate build case, but be ruthless here, because "nothing fits" is also the favourite excuse of a team that simply enjoys building. Nine times out of ten something fits well enough, and the tenth time you had better be certain.
The hidden costs of buying
Buying is not the free lunch the demo makes it look like. The licence fee is the part you can see. The costs that hurt are the ones that arrive later.
- Integration. Every bought tool has to be wired into your systems, your data model, and your auth. That integration is code you own and maintain forever, and it often costs more than the licence.
- Lock in. The more of your business logic that leaks into a vendor's model, the harder and more expensive it becomes to leave. Price rises and roadmap changes are then not your decision.
- The ceiling. A bought product does what its vendor decided it does. The day you need it to do something it was not built for, you are stuck waiting on a roadmap you do not control, or building a fragile workaround around the outside.
The hidden costs of building
Building has its own invisible bill, and it is usually larger than the estimate. The first version is the cheap part. What you sign up for is the rest of the product's life.
- Maintenance is forever. The team that builds it now owns security patches, dependency upgrades, bug fixes, and support at three in the morning. That cost never ends, and it grows as the thing does.
- Opportunity cost. Every engineer building a commodity is an engineer not building your differentiator. This is the real price, and it does not appear on any invoice.
- The knowledge trap. The person who built it leaves, and now you own a system nobody fully understands and cannot easily replace.
The middle path: buy then integrate
The best answer is often neither pure build nor pure buy. Buy the commodity foundation, then build the thin, differentiated layer on top. Take the payment provider, the auth service, the data warehouse off the shelf, and spend your engineering effort on the workflow that sits above them and actually distinguishes you.
Your engineers should be building the top ten percent that makes you different, not rebuilding the ninety percent that every company needs and nobody rewards.
This is where most well run teams end up. It keeps your build effort concentrated on the part that matters, while letting vendors carry the undifferentiated weight. The skill is drawing the line cleanly so that your differentiated layer does not fuse into the vendor's model and recreate the lock in you were trying to avoid.
The sunk-cost trap
The most expensive mistake in this whole area is not the original decision. It is refusing to revisit it. A team builds something, it turns out the market caught up and a vendor now does it better and cheaper, and yet the team keeps pouring effort into their version because they have already invested so much. That reasoning is exactly backwards.
Money and time already spent are gone whatever you choose next. The only question that matters is what serves you best from here. If a bought tool would now do the job for a fraction of the ongoing cost, the years you spent building are not a reason to keep going, they are a reason to stop and redeploy your people onto something that still matters. Review the decision on a schedule, not only in a crisis, and be willing to retire your own work without sentiment.
Putting it to work
For each capability, ask three things. Would a customer choose us because of this? What is the total cost over three years, integration and maintenance included, not just the sticker price? And if we are wrong, how expensive is it to reverse? Buy the commodity, build the differentiator, take the middle path wherever you can, and keep the door open to changing your mind. If you want a second opinion on where your line should sit, our custom software development team does this often, and you can book a free consultation to walk through it.