Business strategy

Build, buy, or stop

Every business has more opportunities than it has time, money, or people. The hard part is deciding which ones deserve investment, which should be bought, and which should be dropped.

Technology makes that harder. A custom platform might be an advantage, or it might become a product you now have to staff. A SaaS subscription can look expensive until you count the engineering hours required to replace it. A roadmap can be technically possible and still unrealistic for the team expected to deliver it.

I work through those tradeoffs with you: what it takes to build and keep software, what it costs, what you are choosing not to do, and a decision you can defend.

I get asked in when the last build-versus-buy call was made in a hallway, when the roadmap keeps growing and nothing comes off it, or when technology is being funded without a clear picture of what it will cost to own.

Technology decisions become business commitments

A team starts an internal tool because the existing product does not quite fit. Six months later the tool needs authentication, reporting, integrations, documentation, monitoring, and someone to maintain it. What began as a small engineering project is now a product the business owns.

Or the company signs a multi-year vendor agreement because the subscription looks cheaper than hiring. The implementation runs long, the integrations are brittle, and the switching cost makes the vendor hard to leave.

Either choice can be right. The failure is making it without the alternatives in front of you. I want the full cost of ownership, the engineering time you will not spend on something else, the operational risk, and what happens if you are wrong. Sometimes the right technical decision is to do nothing.

What I bring

The real cost of each option

I model the paths in front of you: build internally, buy something that exists, outsource the development, extend what you already have, or decline to invest. For each one I include the costs that drop out of the first quote: engineering time, implementation, licensing, infrastructure, integrations, security, training, support, maintenance, the vendor you will depend on, and eventual replacement.

I look past the first delivery into the second and third years, when the original project team may have moved on and the operational work remains. The model is built on assumptions you can see, change, and argue with. You should be able to say what would have to be true for one option to beat another.

The constraint that actually binds

Funding is not always the limit. Engineering capacity, institutional knowledge, management attention, technical debt, or the organization’s ability to absorb a change can bind first. A project can have a compelling return and still be the wrong call if it consumes the only engineers who can keep the core systems running.

I look at who has to do the work, what expertise it needs, which existing commitments compete for those people, and what happens if the timeline slips or a critical person is unavailable. I separate what is technically possible from what you can sustain.

Advantage versus work you should not own

Custom software earns its cost when it is a capability competitors cannot easily copy, a workflow the business actually runs on, or intellectual property worth owning. It earns less when you are rebuilding something mature and widely available because the engineers know how.

I sort which capabilities are worth owning and which belong with a vendor, a platform, or a tool you already pay for. That includes lock-in, who owns the data, what the integration requires, how far you can customize, and what it means later if you have outsourced something critical. The question I ask is whether owning it creates enough value to justify the responsibility.

A roadmap made of decisions

Most organizations have plenty of ideas. What they lack is a way to decide which ideas get people. I judge initiatives on expected value, implementation cost, technical risk, urgency, and the resources they consume. I name dependencies, competing priorities, and projects whose original reason no longer holds.

I write down what happens now, what waits, what shrinks, what gets bought, and what stops. The reasoning sits next to the decision, so the roadmap records commitments.

Pressure on the recommendation

Before I recommend a direction, I look at how it fails. The implementation takes twice as long. Vendor pricing goes up. Adoption falls short. The engineer who understands the system leaves. The business grows faster than the proposed architecture can support.

I use scenarios and sensitivity checks to separate a decision that holds up from one that only works if everything goes well. Where uncertainty remains, I look for the cheapest practical way to shrink it: a proof of concept, a limited pilot, a vendor evaluation, or a short technical investigation. You should know which assumptions you are betting on.

What you leave with

• A build-versus-buy model you can edit, with the costs, the assumptions, and the scenarios, including maintenance and total cost of ownership.
• A one-page recommendation: the direction, the alternatives, the reasoning, the main risks, and the conditions under which I would change my mind.
• A roadmap of what to pursue, what to defer, and what the people you have can actually support.
• A stop-doing list: the projects, commitments, and technical investments I think consume more than they create, with the reasoning written down.
• A picture of the constraints: where people, systems, vendors, and organizational capacity limit the options.

Who I do this with

Founders making their first serious technology investments. Growing businesses whose software costs have become hard to explain. Leadership teams deciding whether to modernize, replace, or retire a system.

I also get called when engineering and the business disagree about a direction. The technical team sees an architecture problem. The executives see a spending problem. Both can be right, and neither view is enough on its own. I translate the technical consequences into business terms, and the business objectives into engineering choices that can actually be staffed.

You still make the business decision. I do the arithmetic with you, challenge the assumptions, and say what the technical consequences are without hiding them in jargon. Fewer commitments, and the ones you keep are ones you can defend: build something worth owning, buy a solution and move on, or recognize that the project should not exist.