AI Has Changed the Build Versus Buy Equation

By Scott Fillman

AI Has Changed the Build Versus Buy Equation

For about twenty years, the standard advice was simple: buy, do not build. Rent the software. Let a vendor carry the maintenance. Save your own people for work that makes you different.

That advice was honest when it was given. It rested on two facts. Building software was slow and expensive. Renting it was cheap at the start and stayed predictable. Both of those facts are moving, and they are moving in opposite directions. I believe the equation deserves to be worked again, in the open, with numbers.

Start with the rent. SaaS is priced by the seat, so the bill grows every time the team grows, whether the new people get value from the tool or not. The price also grows on its own. Vertice, which tracks SaaS pricing across thousands of vendors, put SaaS inflation at 11.4 percent in January 2025, against average inflation of 2.7 percent across the G7 countries. A stack that cost $1,000,000 at the start of 2024 cost about $114,000 more a year later for the same software. And a good share of what is rented is never used. Zylo's 2026 SaaS Management Index found that organizations use about 54 percent of the licenses they provision. The rest sits there, renewing.

There is a second cost that never shows on the invoice. A rented tool was built for the average customer, so your staff reshape their work to fit it. Fields that almost match. Reports that almost answer the question. A spreadsheet kept on the side because the tool does not track the one thing your organization actually runs on. Renting an apartment has the same shape. It is a sensible choice, until the rent keeps rising, the landlord decides what you may change, and you realize you have paid for the place several times over without owning any of it.

Now the other side. The cost of building has fallen, and it fell in a specific place. AI is good at the drafting work of software: boilerplate, routine tests, documentation, standard patterns, first versions of ordinary features. In a controlled experiment published by Microsoft Research, developers using GitHub Copilot finished a standard programming task 55.8 percent faster than the control group. In three field experiments at Microsoft, Accenture, and a Fortune 100 company, covering 4,867 developers, those with an AI coding assistant completed 26 percent more tasks. McKinsey estimates generative AI can improve developer productivity by 35 to 45 percent, speed up documentation by about 50 percent, and speed up refactoring by 20 to 30 percent. The typing was never the whole job. But it was a large and expensive part of it, and that part is getting cheaper every year.

I will state the other evidence plainly, because it matters and because it is where the condition sits. AI does not make every team faster. In a 2025 randomized trial by METR, experienced open source developers working in large codebases they knew well took 19 percent longer with AI tools, while believing they had been faster. Google's DORA research program, surveying nearly 5,000 technology professionals for its 2025 report, concluded that AI works mainly as an amplifier. It magnifies what a team already is. Throughput rises, and delivery stability still suffers when the controls around the work are weak. More code, produced faster, is not the same as better software. Sometimes it is just more to maintain.

That is why my contention has a condition attached to it. The build case works when the people building are engineers and architects at heart. That is not a job title. It is a posture. Engineers decide what not to build. They keep the scope narrow and the stack boring. They write the tests, keep changes small, document the decisions that matter, and review AI output the way they would review code from a fast and confident junior colleague: gratefully, and with checking. AI does the drafting. People stay accountable for the design, the security, and the result. A team that works that way is not just building cheaper. It is building something shaped to the work, on data it controls, that it can maintain on purpose for years.

There is a second practice that changes the long-term math, and it borrows from open source without requiring anything to be public. It is often called InnerSource: applying open source ways of working inside an organization, behind its own walls. The code stays private. The working method is what is shared.

In most organizations, internal software dies in a silo. One team builds a tool, another team cannot see it, and a third team builds a near copy because finding and reusing the first one was harder than starting over. Under InnerSource, internal projects are visible to the whole organization by default. They carry a clear maintainer, a short guide for how to contribute, and issues that any team can pick up. A team that needs the last ten percent the tool is missing does not fork it or file a ticket and wait. It contributes the missing piece, the maintainer reviews it, and every team using the tool benefits from the improvement. A bug fixed once, in the shared component, is fixed for everyone who depends on it.

The evidence for why organizations do this matches common sense. In the InnerSource Commons State of InnerSource 2024 survey, about 68 percent of organizations practicing it named creating reusable software, removing silos and bottlenecks, and knowledge sharing among their motivations. GitHub's guidance for enterprises makes the same practical point: when work is discoverable, teams learn from each other, share expertise, and avoid duplicating effort to recreate common services. Shared building blocks are where this pays first in practice: sign-on and permissions, reporting, integrations with the systems everyone uses, common data definitions. Build those once, well, and let many teams build on them.

InnerSource also answers a fair objection to building. Public open source is not possible for much of what an organization creates. The process is proprietary. The data is regulated. The code would hand a competitor a map. None of that prevents the open source method from working internally. Visibility can stop at the firewall. Contribution can be limited to employees, under the organization's own security and review rules. What changes is not who outside can see the code. What changes is whether your own teams can find it, trust it, and improve it instead of rebuilding it.

I will state its limits plainly too. Putting code in a shared place is not InnerSource. Without maintainer time, documentation, and credit for the people who contribute, shared projects stall, and the owning team becomes a help desk. InnerSource is a commitment to run internal software as a shared asset, with named stewards. Organizations that will not fund that stewardship should not expect the reuse. But for organizations with more than one team, it is how a single build stops being one team's expense and becomes the whole organization's infrastructure.

Here is the shape of the math, with the assumptions stated so you can replace them with your own. Take a tool at $50 per user per month for 100 users. That is $60,000 in year one. Escalate it at 10 percent a year, a little below the rate Vertice reported, and the five-year cost is about $366,000, before implementation, integration, and the staff time spent administering it. Now take a focused custom build at $120,000, with maintenance at 18 percent of the build cost per year, which is inside the usual 15 to 20 percent planning range, plus modest hosting. The five-year cost is about $258,000, and at the end of it you own the system, the data, and the roadmap. These are illustrative figures, not a quote. Run your own. The point is the shape: the rented cost compounds and never ends, while the built cost is front-loaded and then flattens. The longer the system will live, and the more people will use it, the more that shape matters.

Buy still wins, often, and I will say where. Buy when the work is a commodity and every organization needs it the same way: payroll tax filing, email delivery, payment processing. Buy when the need is short-lived, or when a vendor carries a regulatory burden you genuinely do not want. Buy when you have no one who can own a system after it ships, because an unmaintained build is worse than a subscription.

Build deserves a fresh look when the conditions run the other way. The workflow is core to how your organization serves people. You use a small slice of a large vendor product and pay for all of it. The seat count is large or growing. The data is sensitive and belongs under your own control. The system will be in service for five years or more. And you have, or can work with, people who think like engineers and architects. Under those conditions, building is no longer the expensive vanity project the old advice warned about. Increasingly, it is the conservative choice.

I do not start with a preference for building. I start with the numbers, the lifespan, and an honest look at whether the organization has the engineering posture to own what it builds. When it does, AI has made building a better answer than it has been in a long time, and running what gets built as internal open source makes that answer stronger. When it does not, the honest answer is to buy well, negotiate the renewal hard, and revisit the question when the team is ready. Most real decisions land in the middle anyway: buy the true commodities, build the core that makes the organization different, and stop paying rent on the core out of habit.

So run the numbers. Pull three years of invoices and renewal notices for the tool in question. List the features your people actually use, honestly. Decide how long the system needs to live. Check whether another team in your organization has already built part of what you need, because if they have, your build may be much smaller than you think. Put both five-year totals on one page, fully loaded, with maintenance counted on the build side and escalation and administration counted on the buy side. Then decide. The default answer changed because the facts underneath it changed. Decisions should follow the facts.

Sources

Back to Blog