Damian Nomura recently posted something that made me stop scrolling: "88% of enterprises are experimenting with AI. But only 33% have deployed it across their organizations." That gap between curiosity and actual deployment says more about the state of modern business than any hype-filled AI conference ever could.

Damian went further, pointing out that it isn’t the obvious culprits slowing enterprises down:

"Not the technology.
Not the budget.
Not the talent."

Instead, as he put it, the very resources that helped big companies win for decades – large IT teams, governance frameworks, structured processes – are now "anchoring them to the ocean floor." Meanwhile, small companies are sailing past.

That idea resonated with me: for the first time in modern business history, being small is a software advantage.

In this post, I want to unpack Damian Nomura’s argument, add some context, and explore what it means for leaders deciding whether to build or buy software in 2025.

The Inversion of Scale Advantage

For most of the last 40 years, scale was your friend in software.

If you were a large enterprise, you had the budget to buy best-of-breed tools, the people to implement them, and the processes to keep everything under control. Small companies were stuck stitching together spreadsheets and cheap tools, waiting until they were "big enough" to afford what the enterprise world took for granted.

Damian Nomura argues that this equation has flipped.

"For the first time in modern business history, being small is a software advantage."

Why? Because AI has changed the time-to-value curve.

A small team can now:

Design a workflow on Monday
Use AI-assisted development tools to build a custom solution by mid-week
Roll it out to the whole team on Friday

No RFP. No 6-month procurement cycle. No endless integration committee.

Meanwhile, the enterprise is still evaluating vendors, writing requirements, and debating who owns the project.

The advantage isn’t just cost anymore. It’s speed of learning.

What’s Really Blocking Enterprises from AI

If 88% of enterprises are experimenting with AI but only 33% deploy it at scale, something is jamming the system.

Damian Nomura is clear: it’s not the tools, budget, or talent. Most large organizations now have:

Access to the same AI platforms as everyone else
Healthy innovation budgets and transformation initiatives
Smart, motivated teams who want to ship

So what’s in the way?

Legacy processes built for a different era
Governance frameworks were designed for multi-year ERP rollouts, not week-long AI experiments. They assume high cost, high risk, and long timelines. When you apply those assumptions to modern AI projects, everything slows to a crawl.
Risk models that ignore opportunity cost
Traditional risk thinking asks, "What could go wrong if we do this?" but rarely asks, "What could go wrong if we don’t?" As a result, enterprises over-weight compliance concerns and under-weight competitive threats.
Diffused ownership
AI touches every function, which often means it belongs to no one. IT, data, security, and business units all get a say, but no one owns the outcome. Committees form; decisions don’t.
Procurement habits that assume “buy” by default
Many large companies are conditioned to believe that serious solutions must come from serious vendors. Building internally is treated as a risky exception, not a strategic option.

The irony, as Damian points out, is that these were once strengths. Rigor, structure, and governance helped enterprises avoid catastrophic failures. Today, that same machinery can turn a simple AI pilot into a year-long saga.

The New Economics of Build vs Buy

Damian captures the shift in one powerful comparison:

"What used to require a $200,000 development project and six months of vendor management can now happen in a week with one technical person and AI assistance."

That’s not hyperbole. AI-assisted development, no-code/low-code platforms, and highly composable APIs have dramatically lowered the cost and complexity of building custom workflows.

He also cites research:

"Businesses implementing custom solutions report 55% ROI over five years. SaaS implementations? 42%."

The numbers may vary by sector, but the pattern is consistent:

Custom solutions are closer to the actual workflow, so they produce more direct productivity and differentiation.
Generic SaaS tools are easier to justify on paper, but they often require teams to contort their processes to fit the tool.

In a world where AI can help you assemble tailored software quickly, the old logic of "just buy SaaS" is no longer obvious. The question shifts from Can we afford to build? to Can we afford not to?

How Small Companies Turn Speed into Strategy

Damian writes:

"Small companies decide on Monday and deploy on Friday.

Large companies form committees."

This isn’t just a quip; it’s a strategic difference.

Small companies:

Make decisions close to the work
Treat software as a living, evolving asset
Accept that not every experiment needs a business case and steering committee

They can sit a product lead next to a technical builder (or even a single technical generalist), describe the workflow, and use AI tools to build a first version almost immediately. Feedback comes from real usage, not theoretical requirements documents.

Over time, this compounding loop of decide → build → deploy → learn becomes a moat. While larger competitors are still comparing vendors, the smaller firm has already:

Automated key workflows
Captured proprietary data about how their business actually runs
Trained teams to think in terms of capabilities, not just tools

As Damian puts it, "Your advantage doesn’t come from the tools themselves. It comes from your ability to move."

What Large Enterprises Can Do Differently

If you’re in a large organization, Damian Nomura’s post might sound uncomfortably accurate. But it isn’t a death sentence for scale. It’s a call to redesign how scale operates.

Here are practical ways enterprises can respond:

1. Create protected spaces for speed

Spin up small, cross-functional teams with clear mandates and limited scope, and free them from the heaviest governance layers. Give them direct access to users, data (with guardrails), and AI tooling.

2. Redefine governance for low-cost experiments

Not every AI initiative needs the same level of scrutiny as a core banking system migration. Design a "fast lane" for low-risk, reversible experiments with simplified approvals and pre-approved tools.

3. Measure learning velocity, not just ROI

In early stages, the most important metric isn’t cost savings; it’s how quickly you can go from idea to deployed test. Track cycle times: how long from concept to something real in users’ hands?

4. Shift the question from “Which vendor?” to “Which capability?”

Instead of starting with vendor shortlists, start with workflows. Ask: What should this process look like in an AI-native world? Only then decide whether to build, buy, or assemble.

5. Treat custom software as a strategic asset

Damian points to the higher ROI of custom solutions. That isn’t accidental. Custom software encodes your unique way of working. In an AI-enabled world, that uniqueness is increasingly where your competitive edge lives.

2025: The Year to Build, Not Just Buy

Damian Nomura ends his post with a clear thesis:

"2025 is the year to stop buying software and start building it."

I would add a nuance: 2025 is the year to think like a builder, even when you do buy.

Whether you’re a startup or a global enterprise, the organizations that win with AI won’t be the ones with the biggest tech budgets. They’ll be the ones that:

Collapse decision cycles from months to days
Treat software as flexible, composable capability, not fixed product
Use AI to turn ideas into working tools faster than competitors can react

The tools are here. The budgets exist. The talent is ready.

As Damian Nomura highlights, the real question is whether your structures, processes, and habits allow you to move at the speed this new era demands.

This is the moment to look honestly at your own organization and ask: are we experimenting with AI, or are we actually deploying it? And if not, is it really because of technology – or because we’re still operating with a pre-AI playbook?

This blog post expands on a viral LinkedIn post by Damian Nomura. View the original LinkedIn post →