When Did "We Can Build That" Become a Radical Idea?

Try an experiment in your next meeting.

When someone describes a problem—a workflow that's broken, a tool that doesn't exist, a process that wastes everyone's time—say five words:

"We could build that ourselves."

Watch the reaction.

There might be nervous laughter. Raised eyebrows. A patronising smile from someone more senior. A gentle redirect to "what's on the market" or "who we could bring in."

If you're lucky, someone will engage with the idea for thirty seconds before explaining why it's not realistic. We don't have the skills. It would take too long. It's not our core business. What about support? What about security? What about maintenance?

If you're unlucky, the room will simply move on, as if you'd said something slightly embarrassing that everyone agrees to ignore.

The idea that your organisation could build something—actually create a piece of software to solve a problem you have—has become radical. Not in the sense of being bold or visionary. Radical in the sense of being outside the bounds of acceptable thinking.

When did this happen? And what did we lose when it did?

The Shift Nobody Noticed

There was a time, not that long ago, when building was normal.

Companies had IT departments that built things. Not just maintained things, not just integrated things, not just managed vendors—actually built software. Custom applications that fit how the business worked. Internal tools that solved specific problems. Systems that existed because someone inside the organisation created them.

This was messy and imperfect. Lots of those internal systems were poorly documented, hard to maintain, dependent on specific individuals. There were good reasons to be sceptical of the "build everything" mentality.

But somewhere in the course of correcting for those problems, we overcorrected. We went from "be careful about what you build" to "don't build anything." From "make thoughtful build-versus-buy decisions" to "buying is the only option."

The shift happened gradually, through a series of reasonable-sounding decisions:

"Let's focus on our core business." Technology isn't what we sell, so why would we build it? This made sense until "core business" shrank to mean almost nothing, and everything else became someone else's problem.

"Let's leverage best-of-breed solutions." Why build when you can buy something purpose-built by experts? This made sense until you had forty best-of-breed solutions that didn't talk to each other and didn't fit how you actually worked.

"Let's reduce risk." Vendors have support contracts, SLAs, roadmaps. Building is risky—what if it doesn't work? This made sense until vendor dependency became its own risk that nobody measured.

"Let's be agile." Don't build big systems; iterate quickly with modern tools. This made sense until "agile" came to mean "configure vendor platforms" rather than "build what we need."

Each decision was defensible in isolation. Together, they produced organisations that can't build anything. The capability atrophied. The skills dispersed. The muscle memory faded.

And now, when someone suggests building something, it sounds absurd. Not because it's actually absurd, but because it's become unimaginable.

The Imagination Gap

The deepest damage isn't to skills or capacity. It's to imagination.

When your organisation hasn't built anything in years, people lose the ability to envision building. They can't picture what it would look like, how long it would take, what it would require. Building becomes an abstraction rather than a practical option.

I've sat in rooms where someone describes a simple problem—a form that needs to collect some data, a report that needs to aggregate some numbers, a workflow that needs to notify some people—and the entire discussion is about which vendor to evaluate or which consultant to bring in.

Nobody says "we could build that in a week." Not because it's wrong, but because the thought doesn't occur. Building isn't in the solution space. It's not on the menu of possibilities the organisation considers.

This is the imagination gap. The inability to picture your own organisation creating something. The reflexive assumption that solutions come from outside, never from within.

The gap is self-reinforcing. The less you build, the less you can imagine building. The less you imagine building, the less you invest in building capability. The less capability you have, the more unimaginable building becomes.

Until someone says "we could build that" and the room laughs.

What We Lost

The ability to build isn't just a technical capability. It's an organisational capability with implications far beyond IT.

We lost speed. When you can build, you can respond to problems in days or weeks. When you can only buy, you respond in months or years—evaluation, procurement, implementation, configuration. By the time the solution arrives, the problem has often changed.

We lost fit. Vendors build for the general case. They have to—they're selling to thousands of customers. But your organisation isn't the general case. Your workflows have quirks. Your data has oddities. Your people have preferences. Built solutions can fit exactly. Bought solutions require you to change how you work.

We lost ownership. When you build something, you own it. You can change it, extend it, fix it, kill it. When you buy something, you're a tenant. You can request changes. You can wait for the roadmap. You can escalate to your account manager. But you don't control it.

We lost learning. Building teaches you things. About your problem, about your users, about technology, about what works. Even failed builds create learning. Buying teaches you very little. You learn how to configure and integrate, not how to create.

We lost pride. There's something meaningful about using a tool that your organisation created. Something you don't get from using the same platform as ten thousand other companies. A sense of craft, of ownership, of "we made this." That's gone when everything is bought.

We lost optionality. When you can build, you have choices. Build or buy? Build this part, buy that part? Build a prototype to test, then decide? When you can only buy, you have one path. Whatever's on the market. Whatever the vendors offer. Whatever you can negotiate.

The compound effect is an organisation that is slower, less differentiated, less adaptive, and less engaged than it could be. Not because of any single decision, but because of the accumulated weight of all those decisions to buy instead of build.

The Excuses We Accept

Whenever someone does suggest building, the objections come fast. They've become so familiar that they go unchallenged.

"We don't have the skills."

Maybe. But skills can be developed. People can be hired. Capabilities can be built. This objection treats the current state as permanent rather than as a choice.

And the skills required have changed. AI-assisted development means smaller teams can build more, faster. The skill barrier is lower than it was five years ago. It will be lower still five years from now.

"It would take too long."

How long? Have you actually estimated it? Or is this an assumption based on building being hard and slow by definition?

Compare it honestly to the alternative. The vendor evaluation takes three months. Procurement takes two months. Implementation takes six months. Configuration takes three months. You're live in fourteen months—and then you spend another six months dealing with adoption issues because it doesn't fit how you work.

A small team building exactly what you need might take four months. Which is actually faster?

"We need to focus on our core business."

What is your core business? Is it defined so narrowly that everything else must be outsourced? Is technology really not core, or have you just decided to treat it that way?

The most successful companies of the last two decades have treated technology as core, even when technology wasn't what they sold. They built because building gave them capabilities their competitors couldn't buy.

"What about maintenance and support?"

Yes, what about it? This is a real concern, not a fake one. Things you build need to be maintained. But things you buy also need to be maintained—configured, upgraded, integrated, troubleshot. The maintenance doesn't disappear; it just takes a different form.

And when you maintain something you built, you can actually fix it. When you maintain something you bought, you can only report issues and wait.

"It's too risky."

Is it? What are the actual risks, and how do they compare to the risks of buying?

Buying has risks too: vendor lock-in, price increases, roadmap changes, acquisition, sunset. These risks are familiar, so they feel manageable. But they're not smaller than building risks—just different.

The biggest risk of all might be the one nobody talks about: the risk of becoming an organisation that can only buy, never build. The risk of complete dependency. The risk of losing the capability entirely.

The Capability That Disappeared

Here's what actually happened to the ability to build:

The people left. Builders want to build. When organisations stopped building, the builders found other places to work. Startups. Tech companies. Anywhere they could create things. The people who remained were the people comfortable with procurement and integration.

The skills weren't replaced. As builders retired or departed, organisations didn't hire new builders. They hired administrators, analysts, project managers, vendor relationship managers. Important roles, but not building roles.

The tools were locked down. In the name of security and standardisation, organisations restricted what technologies could be used. The approved list became a constraint rather than a foundation. Innovation required permission that was rarely granted.

The processes calcified. Governance designed for large vendor implementations was applied to everything. A small internal build required the same approval process as a $5 million platform purchase. So nobody attempted small internal builds.

The culture shifted. Success became defined as successful implementations, not successful creations. Career advancement came from managing big vendor projects, not from building useful tools. The incentives pushed toward buying.

The stories stopped. Nobody told stories about things we built anymore. The institutional memory of building faded. New employees never saw it happen. Building became something other organisations did, not something we did.

The capability didn't vanish overnight. It eroded, slowly, over years, until it was gone and nobody remembered it had ever existed.

What It Takes to Rebuild

The capability to build can be restored. It requires intention, investment, and patience.

Start with permission. Before skills, before tools, before process—people need to believe that building is allowed. Someone senior needs to say, clearly and publicly, that building is an option. That "we could build that" is a legitimate response to a problem.

Find the builders who remain. Most organisations still have some people who can build, or who could build if given the chance. They're hiding in corners, maintaining legacy systems, doing small automations nobody asked for. Find them. Empower them. Protect them.

Create a space to practise. Building is a skill. Skills develop through practice. Create opportunities for people to build small things without the pressure of mission-critical delivery. Hackathons help. Twenty percent time helps. Protected space for experiments helps.

Update the tools. The approved technology list from 2018 isn't enabling building; it's preventing it. Modern tools—cloud platforms, AI assistants, low-code frameworks—make building faster and more accessible. Let people use them.

Fix the governance. A four-month approval process for a two-week build makes building impossible. Create a fast track for small builds. Risk-proportionate governance. Let teams try things without running a gauntlet.

Celebrate the builds. When someone builds something useful, make it visible. Tell the story. Show the organisation that building is possible, valuable, and rewarded. Create new institutional memories.

Be patient. Capability that eroded over a decade won't return in a quarter. It takes time to rebuild skills, confidence, and culture. The first builds will be rough. Keep going.

The Question Behind the Question

When someone says "we could build that" and the room laughs, the laughter isn't really about the specific suggestion.

It's about a deeper question: What kind of organisation are we?

Are we an organisation that creates, or only one that consumes? Do we shape our tools to fit our work, or reshape our work to fit our tools? Do we develop capabilities, or only acquire them? Do we control our destiny, or rent it from vendors?

The inability to build is a symptom of a larger condition. An organisation that has become passive. That waits for solutions to be sold to it. That has forgotten it has agency.

Rebuilding the capability to build is about more than technology. It's about reclaiming agency. Remembering that you can shape your environment, not just adapt to it. Recognising that the constraints you've accepted aren't laws of nature—they're choices that can be revisited.

"We could build that" shouldn't be a radical statement. It should be an obvious option, considered alongside buying and doing nothing.

The fact that it's become radical tells you something important about what your organisation has lost.

The good news is: you can get it back.