Internal teams can build software faster than ever. Code is essentially free. The harder question is whether the company should own, maintain, support, and fund that product for the next 3-5 years.
Every time someone tells me, "We’ll give it a shot first," I understand and appreciate the instinct. AI has made the first version of internal software dramatically easier to create, and a capable team can now assemble agents, data, models, and a polished interface in a fraction of the time it took a few years ago.
The first version can look fantastic. The problem usually starts after people decide they actually want to use it.
V1 is now the easy part
For the first month, everything feels like proof that building was the right call. The demo works, the data is there, the model produces useful output, and the team has avoided a procurement process and a new software contract.
Then internal users begin asking for reasonable things. Can it connect to Jira? Can the action plan be downloaded into PowerPoint? Can another business unit get access? Can permissions work differently by role? Can it trigger a workflow, support a new data source, or send an alert?
Those requests are a sign that the product is becoming useful. They also mark the point where the original “build” becomes an ongoing product commitment.
The cost model usually stops too early
Most build-versus-buy business cases do a decent job estimating the work required to create the first version. Engineering time, cloud infrastructure, implementation effort, and perhaps some model or data costs are visible enough to put into a spreadsheet.
The long tail is harder to see because it’s spread across teams and budgets. Product ownership, support, security, infrastructure, model updates, data pipelines, integration changes, documentation, training, testing, new features, and knowledge transfer rarely show up under one clean line called “maintenance.”
That makes the initial build look like the main investment when it may end up being the smaller one. A company can spend $1 million getting an internal product into production and then spend another $1 million or more every year keeping it useful, secure, current, and adopted.
Who owns it in 24 months?
This is the question I would push hardest in an executive review. The person who built the first version may be exceptional, but the business case cannot depend on that person staying in the same role, maintaining the same priorities, and remaining available every time something breaks.
People get promoted, move to other teams, take leave, and leave companies. Priorities change. The original builders start working on newer projects, while the internal product they created keeps generating questions, defects, enhancement requests, and user expectations. I have seen this firsthand multiple times now. Waiting on an engineer to make changes to a product they built because they’re off on the next important build is not a great feeling.
Once employees or customers depend on an internal application, model, agent, or workflow, the company owns a software product. Someone needs to own the roadmap, funding, adoption, support model, technical health, and business outcomes long after the original project team has moved on. I’ve been the person people call. It’s distracting at first, and then professionally annoying. It also doesn’t make you friends.
AI raises the maintenance stakes
AI makes this issue more important because the underlying technology is changing so quickly. A traditional internal application might become stale gradually. An AI-enabled product can age much faster as models, APIs, agent frameworks, security requirements, pricing, and user expectations change around it.
A system that felt current six months ago may already be running an older model, carrying outdated prompts or workflows, relying on APIs that changed, or missing capabilities users now see in commercial products. Keeping up becomes an operating responsibility, not a one-time technical task.
The easier it becomes for employees to create internal agents and applications, the more companies should think about the maintenance portfolio they are creating. Ten useful internal tools can be manageable. Ten thousand employee-built agents, automations, and micro-applications create a very different ownership problem.
Buy has a long tail too
A balanced buy-versus-build analysis has to treat the Buy option with the same level of rigor. Software purchased still requires implementation, integration work, configuration, governance, internal product ownership, training, vendor management, and sometimes professional services.
Then you have to add in the possibility of subscription prices rising, usage exceeding the original contract assumptions, vendor roadmaps diverging from your priorities, and switching costs can become painful if the product gets embedded deeply into the way the company operates.
The benefit is that many of the responsibilities associated with maintaining a software product are spread across the vendor’s customer base. Security updates, platform engineering, model migrations, infrastructure, support tooling, and a large portion of the product roadmap are funded across many customers rather than carried by one company.
When Build can be the better decision
There are cases where I would support building even when the five-year financial model is somewhat more expensive. If the capability is central to how the company competes, owning it can create value that does not fit neatly into a software cost comparison.
The case for Build gets stronger when a company has truly unique requirements, proprietary data or intellectual property that creates a durable advantage, significant control or regulatory needs, or enough scale to spread the fixed cost of ownership across a very large user base or a high-value business process.
Company capability matters just as much. A software business with strong product management, engineering, data, AI, security, and platform disciplines is in a very different position from a company where building and operating software is outside the core competency of that company.
Ten questions to answer before approving Build
I would separate the decision into three areas: strategic ownership, economics and scale, and the company’s readiness to operate what it builds. A “yes” to the strategic questions should give Build credit, while weak answers on readiness and economics should pull the decision back in the other direction.
- Is this capability core to how the company competes? Build deserves more credit when owning the capability can materially change customer value, economics, speed, intellectual property, or business performance.
- Would ownership create an advantage a vendor cannot reasonably provide? Custom is valuable when it creates real differentiation, not simply because the company prefers its own version of common functionality.
- Are the requirements genuinely unique? A long feature wish list is different from a requirement that commercial products cannot meet without major compromise.
- Do control, intellectual property, data, or regulatory requirements make ownership strategically important? Some capabilities justify greater internal ownership because the company needs tighter control over architecture, data, models, or decision logic.
- Is there enough scale to spread the fixed cost of building and maintaining the product? A multimillion-dollar internal product can make sense across tens of thousands of users or a high-value process and look irrational across a few hundred occasional users.
- Does the financial case include at least three years, and preferably five, of full lifecycle cost? Include product ownership, engineering, support, infrastructure, security, integrations, model updates, enhancements, training, turnover, and retirement or replacement costs.
- Is there a named product owner who can remain accountable for the next 24 to 36 months? Someone needs to own the roadmap, adoption, funding, support model, and outcomes after the original build team moves on.
- Is building and operating software, data, and AI products a demonstrated core competency? Technical feasibility alone is a weak reason to build. Durable ownership requires product, engineering, security, support, and lifecycle disciplines.
- Can the company continuously maintain integrations, security, data pipelines, models, APIs, and infrastructure? The product starts aging the day it launches. The company needs the capacity and funding to keep pace with change.
- Can the business tolerate the delivery, talent, continuity, and adoption risk of building? The strategic upside has to justify a longer delivery curve, key-person risk, internal competition for resources, and the possibility that adoption never reaches the scale required for the economics to work.
The recommendation should be allowed to come out either way
I do not think a useful buy-versus-build model should begin with a bias toward buying. If a capability is strategic, differentiated, supported by real internal competency, and economically sensible at scale, the model should tell the company to build it.
The same model should make it difficult to justify Build simply because a team can create an impressive prototype. The five-year view forces the company to price the part of ownership that arrives after the demo, when the product needs a roadmap, support, updates, integrations, security, funding, and someone who will still care about it two years later.
The one metric I think is most important here
One number I would put on every executive page is the ratio of ongoing maintenance and ownership cost to the original build. It makes the hidden part of the business case visible and gives leaders a much better sense of what they are actually approving.
The prototype proves that the company can build the product. The three-to-five-year model determines whether owning that product is a good use of the company’s money, people, and attention.
