The decision that matters now is who you build with.

01 · The question changed

Buy-only advice was built for a different era.

For twenty years the safe advice was to buy software, never build it. That advice made sense when custom development took years and seven figures. Both conditions have changed. Off-the-shelf tools now carry documented waste that compounds at every renewal. The cost of building systems fitted to your operation has fallen hard. And the failure pattern of companies that build alone is now well mapped, which means it can be avoided. The decision that matters in 2026 is who you build with.

02 · What you actually pay for when you buy

Generic software is built for the average business in its category.

Your business is specific. You pay for that gap three ways.

You pay for what you never use. Companies with fewer than 500 employees run an average of 152 software subscriptions, and industry benchmark data shows only about half of paid licenses get used at all. Usage telemetry across 615 software products found that 80 percent of features are rarely or never touched.

You pay more every year for the same gap. SaaS list prices have been rising near 13 percent annually, with increases concentrated at renewal, when switching is hardest. The product does not fit your operation any better at the higher price.

You pay in labor to glue it together. Each tool holds a slice of your data, and your people reconcile the slices by hand. Researchers writing in Harvard Business Review measured knowledge workers switching between applications roughly 1,200 times per day, losing just under four hours a week to reorientation. That is about 9 percent of the working year spent finding your place again.

Buying still wins for commodity functions. Payroll, accounting, and email are solved problems, and you should buy them. The waste concentrates in the systems that run your core operation: quoting, scheduling, dispatch, job tracking, client workflows. That is precisely where average fits you worst, and where you are already paying people to work around the software.

03 · Why building alone goes wrong

Project blowups have known causes, and they form before any code is written.

You have likely seen an internal project fail, or know someone who has. The data explains what you saw. Peer-reviewed research covering thousands of IT projects shows cost overruns follow a power law. The typical project lands near plan. Then one in six becomes an outlier, with cost overruns averaging 200 percent. The distribution has a fat tail, and the tail is where projects kill budgets.

When RAND interviewed 65 veteran AI engineers about why projects fail, 84 percent pointed to leadership-driven root causes: solving the wrong problem, shifting priorities midstream, automating a process that was already broken.

Operations-heavy businesses hit two additional walls. The first is key-person risk. Internal systems tend to live in one or two heads, and the business is exposed the day those heads leave. The second is maintenance. A system you build alone is a system you staff forever, in a talent market where you compete against software companies.

Custom systems succeed when those causes are designed out from the start: modular scope, short delivery cycles, and a process fixed before it gets automated. Experienced builders carry that playbook from dozens of prior projects. First-time internal teams write it as they go, at your expense.

04 · What changed the math

Building fitted systems got cheap.

Goldman Sachs CIO Marco Argenti said this year that AI has made it cheap enough to build smaller applications in-house, that internal tools which took months now ship in days, and that the bank has already terminated some vendor contracts as a result. That is a cost statement, on the record, from one of the most conservative technology buyers in the world.

The pattern is broad. In a late-2025 survey of 817 technology teams, 35 percent had already replaced at least one SaaS product with something they built, and 78 percent expected to build more in 2026. The categories under the most pressure are workflow automation, internal admin tools, and CRM. Those are operational systems, the exact category where generic software fits worst.

One caveat: AI speeds development unevenly. Controlled studies show large gains on well-scoped work and smaller gains on complex systems. The leverage is real, and it accrues to teams that have shipped these builds many times before.

05 · What the successful minority does differently

Partnered builds succeed at roughly twice the rate of internal ones.

A 2025 MIT study of enterprise AI adoption found that roughly 95 percent of corporate GenAI pilots produced no measurable P&L impact. The roughly 5 percent that worked shared a pattern. Organizations that built with specialized external partners reached successful deployment about 67 percent of the time. Purely internal builds succeeded about one third as often. The winners also behaved differently as buyers: they demanded deep customization to their workflows and judged vendors on operational results.

The second half of the pattern predates AI by decades. Michael Hammer warned in 1990 that automating a broken process locks the breakage in. MIT economists later showed that returns on new technology depend on redesigning the work around it, and that bolting new tools onto old processes can produce negative returns.

Klarna is the clearest recent case of both truths at once. AI plus aggressive process simplification let a regulated, bank-licensed company drop Salesforce and Workday for a lighter stack of custom and alternative tools. Its AI assistant handled work equivalent to 700 customer service agents in its first month. Then quality slipped where automation had outrun process design, and the company publicly rehired human agents in 2025. Custom systems work. Sequencing and judgment determine whether they work for you.

06 · How to do this without becoming the cautionary tale

Diagnose, Build, Embed.

Avolis was built for this decision. We work as a forward-deployed partner inside operations-heavy businesses, and our method maps directly onto the failure modes above. Diagnose comes first: we map how your operation actually runs and fix the process before anyone writes code, because automating a broken process is the oldest failure in the book. Build comes second: modular systems, shipped in short cycles, shaped to your workflows and your standards. Embed comes last: we stay until your team runs the system without us, because a system nobody adopts returns nothing.

The first step is small by design. The AI Readiness Evaluation is a short, fixed-scope assessment that maps where your operation loses money to misfit software and manual workarounds, what a custom build would return, and in what order to sequence it. If the numbers say your current stack is the right answer, the evaluation will say that too. You will know either way before committing to anything.

Sources