Key Takeaways
- McKinsey's 2026 State of AI survey found that 32% of organizations decided against buying at least one software product or feature because they could build it in-house with AI coding tools.
- The first version costs less to build than it used to. Owning it costs what it always did: maintenance, security reviews, and someone who understands how it works.
- Buy when the function is common, regulated, or a system of record. Build when the workflow is how you win, or when bought tools keep bending your process.
- Most operations leaders have four options, not two: buy, configure an application platform, build in-house, or build with a partner.
- The question that sorts all four is who owns it in year two, by name.
A third of organizations have already decided against buying software because they could build it instead. That's from McKinsey's 2026 State of AI survey, published in August.
So if you're wondering whether build vs. buy is coming for your operation, it's already here. With 2027 budgets being set right now, the conversation is about to get formal.
Here's where we land: building the first version has gotten cheap, and owning it still costs what it always did. Most of this decision lives in year two.
Why is build vs. buy suddenly on every operations leader's desk?
Because the math on the first version changed.
McKinsey's survey covered 1,719 leaders in 97 countries between May 4 and June 8, 2026. Nearly a third said their organization decided against buying at least one software product or feature because it could build the functionality in-house with agentic coding tools.
Gartner sees buyers shifting too. In its July 1 release, analyst George Brocklehurst said that "enterprise buyers will deemphasize buying more new tools or dashboards."
Faster building hasn't meant better returns for most. Domino Data Lab's July survey of 639 enterprise AI leaders found that 57% say their AI returns still trail their spending, unchanged since 2025.
That's why this decision deserves more than a demo.
What does it cost to own software after you build it?
Lemkin has a second story. In a separate post, he wrote that he maintains the dozen apps he's built every single day, 30 to 60 minutes of it, and he audits the sponsor portal for security every month or two.
The research points the same way.
A May 2026 study followed AI-generated files in 100 popular open-source repositories for six months. Humans made 83% of the follow-up commits on those files, and the AI agents that wrote the code made about 17%.
Those are open-source projects and not operations apps, so take the number as a signal. The signal is that the tool that writes the code mostly doesn't come back to fix it.
Jeremiah Stone, the CTO of SnapLogic, told Forbes that "creating an application is trivial compared to maintaining it through time."
That matches what we've seen in 17+ years of building and supporting operational apps. A build is a project with an end date, and maintenance is a job with no end date.
One limit worth stating: nobody has published a clean number for what it costs a mid-market operations team to keep a self-built app running, and we'd rather say so than make one up.
We can tell you what goes on the bill: fixes, security reviews, changes when your process changes, and a person who understands how it works.
When that person changes roles, the app needs a new owner who inherits whatever the tool produced. We wrote about what a half-finished build costs in The Hidden Cost of a Half-Built Quickbase App.
When should you buy instead of build?
When the function is common. If thousands of companies run the same process and a vendor has a large team improving it, let them. Lemkin's rule is "if you can buy it, buy it," and for most common functions we agree with him.
Buy when the system holds regulated or financial data, too. A vendor brings security reviews, audit history, and a contract.
Buying doesn't settle the question by itself. Plenty of bought software ends up abandoned in the field because nobody planned for adoption, and a good system of record still needs the rest of your operation connected to it.
We've written about why construction's software graveyard keeps filling up and why Procore alone doesn't solve operations.
When does building make sense?
When the workflow is how you win. Bid intake, crew scheduling, compliance handled your way. If a competitor could buy the same tool tomorrow, it gives you no edge, and if it's your process, a bought tool makes you bend it.
It also makes sense when bought tools keep getting you most of the way there and the rest lives in spreadsheets and inboxes. And when several systems have to keep talking to each other through every upgrade.
Building with AI raises the stakes on the plan behind it. An AI-built app on top of an undefined process inherits the mess faster, which is why we say Structure Before AI. Settle how the work should flow before anybody writes a prompt. We covered where vibe-coded tools stop being enough in Beyond the Vibe.
What are your options besides building it yourself or buying it off the shelf?
Most operations leaders have four options, and the two in the middle get less attention than they should.
| Path | It fits when | Watch for | Who owns it in year two |
|---|---|---|---|
| Buy packaged software | The function is common, the data is regulated, or you want a vendor to call | Your process bending to fit the product, and adoption | The vendor owns the product. You own adoption and configuration. |
| Configure an application platform | Your process is specific but the building blocks are common | Outgrowing the platform, and needing an admin who knows it well | You, or a partner on retainer |
| Build in-house with AI tools | A narrow internal tool, low-stakes data, and a builder who will stay | Security, upkeep, and one person holding all the knowledge | One named person on your team |
| Build with a partner | The workflow is how you win, it touches core systems, and you don't want to staff a development team | A partner who disappears after go-live, and unclear terms on who hosts it and who can change it | Shared, in writing |
Paths two and four are where most mid-market operations land. A platform such as Quickbase or Mendix gives you building blocks that are already secured and supported. A partner gives you a development team without hiring one.
For the partner path, the test is who's still in the room after go-live. We partner, we don't vanish, and our Ongoing Development Plan exists for exactly that stretch, when the app has to change with your business.
How do you decide? Five questions for your next leadership meeting
- Is this how we win, or how everyone runs? If it's how everyone runs, buy it.
- Who owns it in year two, by name? A person or a partner. If you can't name one, you're not ready to build.
- What data does it touch, and what happens if it's down for a day? Regulated or customer-facing data raises the bar for whoever is accountable.
- Does it have to keep talking to our other systems after every upgrade? Integrations are the part that keeps needing work after launch.
- What's the exit? If you buy, how do you get your data out? If you build, what happens when the builder leaves?
The answer to number two is what we mean by HI × AI = FIRE. AI supplies the speed, and a person who owns the outcome supplies the judgment. AI without that person is just speed with no steering.
Get a straight answer on build vs. buy for your operation
If you're weighing a purchase against a build, start with what you already run. Our App Checkup is a focused assessment of the Quickbase, Mendix, or custom applications you use today, typically about 10 hours over one to two weeks. You get clear, prioritized recommendations and a roadmap, without a 50-page report to file away.
If you haven't built anything yet, a discovery call works too. We'll tell you when buying is the right answer. No pressure, no pitch.
Frequently Asked Questions
Should we build or buy operations software?
Buy when the function is common or sits on regulated data. Build when the workflow is how you compete, or when bought tools keep forcing your process to bend. Configuring an application platform and building with a partner are two more options. The question that sorts all four is who owns it in year two.
Is it cheaper to build or buy software now?
The first version costs less to build than it used to, which is why McKinsey found that 32% of organizations decided against buying at least one software product or feature. Ownership hasn't gotten cheaper: maintenance, security reviews, and someone who understands how it works. Compare the year-two bill, not the launch price.
Who maintains software built with AI?
Mostly people. In a May 2026 study of 100 open-source repositories, humans made 83% of the follow-up commits on AI-generated files, and AI agents made about 17%. Plan on a named owner in your organization or a partner on retainer.
When should a company not build its own software?
When the function is common, when it holds regulated data you need a vendor to stand behind, or when nobody can be named as the owner a year from now. Test what your current tools can do first, because one you already pay for may cover most of it.
Can we replace a SaaS tool with something AI-built?
For a narrow internal tool, often yes. Jason Lemkin replaced a sponsor portal in about a day and a half and still audits it for security every month or two. Systems of record and regulated data usually stay bought, with the building done around them.
