Build vs Buy vs Bend: A CTO's Framework for Technical Decisions Under Constraint

I have never found "build versus buy" to be a very useful framing.

It sounds clean. It gives the room two options. Either we build the thing ourselves, because our needs are special, or we buy the thing, because someone else has already solved it.

But most real technical decisions do not fit that neatly.

There is almost always a third option sitting in the middle: bend.

Bend is when you take something that already exists and make it fit. You configure it. Extend it. Wrap it. Self-host it. Build around it. Integrate it into your operating model. Sometimes you fork it, although I would treat that as a last resort rather than the default move.

A surprising amount of engineering leadership lives in that middle space.

The mistake is pretending the decision is binary when the real question is more practical: given our constraints, how much ownership should we take on?

That is the part that matters.

Not whether building is more "pure". Not whether buying is more "mature". Not whether open source feels better than a vendor. The right answer depends on what is core, what is reversible, what it costs to operate, and what the team can actually carry.

The decision should be made by constraint and reversibility, not ideology.

The calls compound

These decisions matter because they compound.

One build decision can turn into a platform the team maintains for years. One vendor decision can turn into a dependency that touches every workflow. One self-hosted tool can quietly become a production system with backups, upgrades, security patches, monitoring, incident response, and someone's weekend attached to it.

The cost is rarely obvious at the moment of choice.

In the meeting, the question often sounds simple. Should we build this? Should we buy it? Can we use the open-source thing? Can we just wire something together?

But the real decision is bigger than the first implementation. You are deciding where complexity will live. You are deciding who will own it. You are deciding how easy it will be to change your mind later.

That is why I try to avoid strong ideological positions on this.

I have seen teams build things they should have bought. I have seen teams buy things they never properly adopted. I have seen teams self-host "free" tools that became expensive because nobody accounted for the operational burden. I have also seen teams buy a vendor solution too early, only to discover they had traded engineering complexity for commercial and process complexity.

Both failure modes are real.

The job is not to always build. The job is not to always buy. The job is to know what kind of problem you are actually dealing with.

Start with core versus context

The first question I ask is whether the capability is core to the business.

Not "is it technically interesting?" Not "could we build it better?" Not "does the team want to own it?"

Is it genuinely differentiating?

If the answer is yes, building may be worth it. If the capability expresses something central about how the company wins, how the product behaves, how customers experience the value, or how the business creates leverage, then owning more of it can be the right call.

But most software inside most companies is not that.

Most of it is context. Important context, but still context.

Authentication, billing, analytics plumbing, deployment workflows, internal admin, generic content management, observability, ticketing, data syncs, permission panels, notification systems — these things matter, but they are rarely the reason a customer chooses you.

Building undifferentiated plumbing is a slow, expensive way to lose.

That does not mean you should blindly buy all of it. It means the default posture should be sceptical. If we build this, what advantage are we creating that we could not get by buying or bending something existing?

Sometimes the answer is control. Sometimes it is regulatory fit. Sometimes it is latency, scale, data sensitivity, or a product requirement that genuinely cannot be met another way.

That is fine.

But "we can build it" is not a reason. Good teams can build almost anything. The question is whether they should.

Bend is usually where the answer lives

This is why I like naming the third option.

Bend gives you a more honest vocabulary for the work most teams actually do.

You might take a mature open-source tool and wrap it with a thin internal interface. You might buy a vendor product but constrain how deeply it enters your architecture. You might self-host a tool because the data or compliance profile requires it. You might extend a platform in a narrow way rather than replacing it. You might accept a slightly awkward workflow because it avoids six months of custom development.

None of that is failure.

That is engineering under constraint.

The skill is knowing how far to bend before you are really building anyway.

A heavily customised vendor product can become worse than custom software, because now you have custom behaviour inside a system you do not fully control. A forked open-source project can look cheap until you are permanently downstream from the mainline. A pile of wrappers can become its own platform with unclear ownership.

Bend is powerful, but it is not magic. It is still a choice to own some complexity.

The question is how much, where, and for how long.

Reversibility is the hidden axis

The most useful axis in these decisions is reversibility.

Some decisions are two-way doors. If we are wrong, we can unwind them without much pain. Use this library. Try this workflow. Add this small service. Run this process manually for a month. These decisions do not need heavyweight governance. Decide quickly, write down the assumption, and move.

Other decisions are one-way doors, or close enough to deserve more care.

Adopting a vendor that becomes the system of record. Choosing a data model that many teams depend on. Building a platform others will integrate with. Selecting an infrastructure pattern that shapes hiring, operations, and cost. These are harder to reverse. They deserve more rigour.

A lot of teams use the same decision process for both, which is where things go wrong.

They over-process small, reversible decisions and under-think the ones that will be painful for years.

I have found it more useful to ask: if we are wrong, how expensive is it to change our mind?

If the answer is "not very", move. If the answer is "very", slow down.

That sounds obvious, but it cuts through a lot of theatre.

Cost is operational, not just financial

The second trap is treating cost as licence versus salary.

A vendor has a price. A team has salaries. Open source is free.

That framing is too shallow.

The cost that matters is the cost of operating the choice.

A free open-source tool is not free if you need to run it, patch it, secure it, back it up, monitor it, upgrade it, and carry the incident response when it breaks. A vendor is not cheap if every workflow has to contort around its model. A custom-built system is not cheap because the initial version was quick.

Cost includes maintenance. Cost includes support. Cost includes migration risk. Cost includes vendor lock-in. Cost includes the cognitive load on the team. Cost includes the opportunity cost of having good engineers maintain something that does not differentiate the business.

This is where the answer often changes depending on the organisation.

A mature platform team may be able to self-host something safely. A small product team with thin operational coverage probably cannot. A regulated environment may need controls that make a vendor harder to use. A scale problem may justify owning a layer that would be overkill somewhere else.

The same decision can be right in one company and wrong in another.

That is not inconsistency. That is context.

Capacity and time-to-value matter

The theoretically best architecture is not always the right decision.

Sometimes the team does not have the capacity. Sometimes the business needs value this quarter. Sometimes the risk is not technical elegance, but waiting too long. Sometimes a vendor gets you 80 percent of the value quickly, and the remaining 20 percent is not worth the delay.

This can be uncomfortable for engineers, because we can see the flaws.

The product does not fit perfectly. The API is not quite how we would design it. The workflow has some friction. The abstraction is not beautiful.

But the job is not to optimise for beauty in isolation. The job is to deliver the right outcome under constraint.

I have made calls where the best answer was "not yet". Not "never". Not "we do not care about this." Just: the current constraint does not justify the complexity today.

That is a complete technical decision.

For example, deciding not to introduce a pooler yet can be the right call if the current bottleneck is elsewhere, the team does not need the operational surface area, and the trigger for revisiting is clear. The important part is not being passive. It is knowing what would change the answer.

Right for now, with a known trigger to change, is a strong decision.

Guard both failure modes

Build-versus-buy debates often become arguments between two caricatures.

One side sees every vendor as lock-in and every external dependency as weakness. That leads to NIH: building everything, owning too much, and slowly drowning in self-inflicted maintenance.

The other side sees every custom build as waste. That leads to buying complexity the team cannot shape, operate, or escape.

Both are expensive.

The framework should guard against both directions.

Before building, ask: is this core, and are we willing to own it properly?

Before buying, ask: what happens if this becomes central and we need to change it later?

Before bending, ask: are we keeping the adaptation thin, or are we creating a custom system in disguise?

The best technical leaders I know are not allergic to any of the options. They are allergic to pretending an option has no cost.

Write down the decision and the trigger

The final step is simple, and teams skip it all the time.

Write down the decision.

Not a novel. Not a ceremony. Just enough to capture the reasoning.

What did we choose? Why did we choose it? What constraints mattered? What alternatives did we reject? What would make us revisit the decision?

That last question is the important one.

A decision without a revisit trigger slowly turns into folklore. Six months later, nobody remembers whether the constraint still exists. A choice that was sensible at the time becomes an unquestioned default.

The trigger keeps the decision alive.

If usage reaches this scale, revisit. If the vendor cost crosses this threshold, revisit. If compliance requirements change, revisit. If the team grows a platform function, revisit. If the integration becomes business-critical, revisit.

This is how you avoid both over-engineering and under-engineering. You make the best call for the current constraint, but you do not pretend the world will stay still.

The principle

Build, buy, and bend are all valid moves.

The leadership skill is knowing which kind of ownership you are accepting, and whether that ownership matches the value you are trying to create.

Build what differentiates.

Buy what is mature, non-core, and cheaper to adopt than to own.

Bend when existing tools can get you most of the value, as long as the adaptation stays understandable and reversible.

And in every case, weigh the cost of operating the decision, not just acquiring it.

That is the part I care about most. Technical strategy is not about proving a preference. It is about making clear decisions under constraint, with enough honesty to change course when the constraint changes.

Decide by constraint and reversibility, not ideology.

That is the framework I would build around.