Building Capability

Chapter 8: Technology Is the Last Decision, Not the First

Before you read — by the end of this chapter you will understand:

• Why technology should be the last decision, not the first
• How the cloud changes the fundamental economics of capability building
• When to use off-the-shelf tools, custom builds, or a hybrid approach
• The nucleus model: how to build outward from your core expertise
• How to avoid the most common technology trap — building for the technology instead of for the outcome

A few years ago I watched a company implement one of the big enterprise sales platforms — the kind with the glossy demo, the enthusiastic account manager, and the price tag that makes you wince.

Six months in, something strange had happened. The sales team wasn’t using it the way a sales team should. They were using it the way the platform expected them to. Leads were being categorised into stages the platform had defined. Reports were being run because the platform made those reports easy. Meetings were being logged because the platform prompted for them. The whole operation had quietly reorganised itself around what the software could do — rather than the software being built around what the business needed to do.

And the deeper problem: they were a SaaS business. Their customers found them online, trialled the product, converted through a landing page, and onboarded themselves. The entire customer journey was digital and self-directed. What they actually needed was a sharp onboarding sequence, a well-designed trial experience, and a way to see where people dropped off. None of that lived in the platform they’d bought. Instead, they had a sophisticated pipeline tool built for a sales team making phone calls and booking meetings — which they weren’t.

The technology had made the decision. The business had followed.

The Technology-First Trap

Here’s how it usually goes.

Someone in the organisation — or more often, someone selling to the organisation — gets excited about a technology. Maybe it’s AI. Maybe it’s automation. Maybe it’s a new platform. Maybe it’s a cloud service that does something genuinely impressive. The demos are compelling. The possibilities seem endless.

And so the organisation starts working backward from the technology. What can we do with this? Where can we apply this? How do we get this into our processes?

That is precisely the wrong direction.

Technology should answer a question, not ask one. The question has to come first: what does our customer need? What does our team need? What does our business need to be able to do that it currently can’t? What risk do we need to eliminate? What friction do we need to remove?

When you start from those questions, you end up with technology decisions that serve a purpose. When you start from the technology, you end up with impressive systems that don’t solve the problems that actually matter — or worse, you end up with a business that has quietly reshaped itself to fit a tool, rather than the other way around.

I’ve seen this play out too many times to count. Organisations that buy expensive platforms they then bend their business processes around. Teams that implement AI tools because they feel like they should, without any clarity about what problem the AI is solving. Projects that generate great demos but never get adopted by the people they were built for.

The trap isn’t buying bad technology. It’s letting good technology ask the questions that only your business should be answering.

What the Cloud Actually Changes

That said, I don’t want to dismiss technology as irrelevant to the conversation. The cloud genuinely changes the economics of capability building in ways that matter enormously for the kinds of organisations I work with.

Before cloud infrastructure, building a custom software capability was expensive, slow, and risky in ways that made it inaccessible to most organisations below a certain size. You needed servers. You needed IT staff to maintain them. You needed large upfront capital. You needed to commit to a technology decision years in advance and live with it.

The cloud removes most of those constraints. It changes what’s possible in four specific ways that I keep coming back to.

It removes time and distance. A cloud-based system can be accessed from anywhere, on any device, at any time. That sounds obvious now, but it’s actually a profound shift in what’s possible for organisations with distributed teams, mobile workforces, or customers who need to interact with you outside of business hours.

It breaks the staff-to-revenue lockstep. In a traditional service business, growth usually means hiring — more revenue requires more people to deliver it. Cloud capability can break that equation. If you can put parts of your expertise or your process into a system that customers or junior staff can access directly, you can grow revenue without a proportional increase in headcount. That changes the economics of the business fundamentally.

It enables global reach without global cost. A well-built cloud platform can serve customers in any market without requiring a physical presence in that market. The infrastructure cost of serving one hundred customers is not dramatically different from serving ten thousand. That’s a different kind of business.

It makes iteration cheap. In a traditional software build, changes were expensive because the code was bespoke, the test cycle was long, and the deployment required planned downtime. In a cloud environment, iteration is fast and relatively cheap. You can ship, learn, adjust, and ship again in a cycle that was simply not possible before.

These aren’t reasons to start from the technology. They’re reasons why, once you’ve decided what you’re trying to achieve, the cloud opens up options that didn’t exist a generation ago.

Build, Buy, or Borrow?

One of the most important decisions in any capability build is whether to build something custom, buy an off-the-shelf solution, or use a combination of both.

There is no universal right answer. But there is a wrong way to approach the question — and that’s starting with a preference before you’ve understood the situation.

I see this on both sides. Organisations that reflexively buy off-the-shelf because custom sounds expensive and risky. And organisations that reflexively build custom because they don’t trust external platforms or believe their situation is so unique that nothing on the market will fit.

Both instincts are understandable. Both get people into trouble.

Here is the framework I use.

Buy off-the-shelf when the process is generic — when what you’re doing is not in any meaningful way different from what thousands of other organisations do. Accounting. Payroll. Basic CRM. Project management. These are solved problems, and spending money to solve them again in a custom way is waste. The market has built good tools for these. Use them.

Build custom when the process is the source of your competitive advantage — when the way you do something is genuinely distinctive and that distinctiveness is worth preserving. If the core of what makes your business valuable is the way your expertise is applied, the way your customers experience working with you, or the proprietary knowledge your team has built over decades, then that is worth building. Off-the-shelf will flatten the thing that makes you different.

Use a hybrid when neither extreme is right — which, in practice, is most of the time. A custom layer on top of a commodity platform. Proprietary logic that runs inside a standard workflow tool. A custom customer experience that draws on off-the-shelf infrastructure underneath.

The key question is: where is your competitive advantage?
Build there. Buy everywhere else.

The Nucleus Model

I want to give you a mental model for how custom capability grows over time. I call it the nucleus model.

Think about the core knowledge and expertise in your organisation — the thing your best people do, the thing that took years to learn, the thing that clients pay you for.

That’s the nucleus. It’s the most valuable thing in the business. It’s also the thing that currently lives in those people’s heads, in their habits, in their judgment. It’s not documented, not systematised, not transferable.

The first phase of a capability build is almost always about getting that nucleus out of people’s heads and into a system. Documenting the logic. Encoding the decisions. Making the expertise accessible.

Once you’ve done that — once the nucleus is captured — you can start to build outward.

First layer: guided by experts. The system captures the knowledge, but a senior person is still in the loop to guide how it’s applied. The system does the heavy lifting; the expert checks the output and handles the exceptions.

Second layer: done by juniors. The system plus the documentation is sufficient for someone with less experience to apply the expertise reliably. The expert is now a reviewer rather than a doer. They handle escalations and edge cases. Their capacity is freed for more complex work.

Third layer: given to customers. With the right design, parts of the expertise can be put directly into the hands of customers. Self-service tools. Guided experiences. Automated recommendations. The expertise now scales without any human involvement at all.

Each layer compounds the value of the nucleus. Each layer reduces the cost of delivery. Each layer extends the reach of what the organisation can do.

But it starts at the nucleus. Always. You can’t build the outer layers if the core isn’t solid.

The APS Case Study: Nucleus in Practice

I worked with APS — a business that had spent decades building desktop applications for accounting practices. Thirty established products. A reputation that opened doors across Australia. A loyal customer base and predictable revenue streams.

But the conversations had shifted. Every prospect meeting began with the same question: “When will this be available in the cloud?”

The pressure came from multiple directions. Existing customers wanted modern accessibility without losing the sophisticated workflow management that differentiated APS from generic accounting packages. Potential customers were evaluating cloud-first competitors. Investors expected proof of transformation — not promises about future capability.

The strategic bind was real: he needed to demonstrate cloud capability to secure future investment and customer confidence, but couldn’t afford to divert his development team from the thirty existing products that generated current revenue. Previous attempts to scope a full transition had suggested eighteen months to two years of development — too long for market expectations and investor patience.

This is where the nucleus model becomes practically useful. Rather than trying to rebuild everything, we identified the nucleus: the specific workflow management expertise that differentiated APS from generic alternatives. That was what customers were actually paying for. Everything else was infrastructure.

The first phase wasn’t a full cloud migration. It was a reference application — a single, well-built demonstration of cloud capability built around that nucleus — that proved APS could deliver modern cloud architecture without sacrificing the depth that existing customers valued. Scope was controlled. Timeline was manageable. And the output was something investors could see and customers could evaluate.

That reference application became the proof of concept that unlocked the next phase of investment. Not because it solved every problem — it didn’t. But because it demonstrated, with something real and working, that the organisation understood its own nucleus and could build outward from it in a modern environment.

The technology choices that made this possible were entirely secondary to the strategic insight: know what your nucleus actually is before you decide what to build.

A Note on AI

I can’t write a chapter about technology choices in 2025 without addressing AI directly.

AI has changed the landscape for capability building in ways that are genuinely significant. I don’t say that lightly — I’ve lived through enough technology hype cycles to be cautious about superlatives.

But the specific capability that AI adds — the ability to process language, to recognise patterns in large datasets, to generate outputs that previously required human judgment — does genuinely extend what’s possible in the nucleus model. There are categories of expertise that were previously impossible to encode because they required judgment that couldn’t be reduced to rules. AI doesn’t fully solve that problem, but it moves the line meaningfully.

What I’d caution against is the assumption that AI changes the fundamental logic. You still have to start from the question, not the technology. You still have to build foundations before you build superstructure. The nucleus still has to be real before you can scale it.

AI is a powerful addition to the toolkit. It is not a substitute for the process.

The Rule

I’ll finish this chapter with a simple rule that I’d encourage you to apply to every technology decision you face.

Start from the outcome. Work backward to the technology.

Not: “What does this technology enable?” But: “What outcome do we need? What technology makes that possible at the right cost, the right speed, with the right trade-offs?”

When you start from the outcome, technology decisions become clear. Not easy — there are always trade-offs and uncertainties. But clear in the sense that you have a criterion to evaluate against.

Technology in service of outcome. Never the other way around.

Tool: The Build / Buy / Borrow Decision Guide

For each significant capability on your roadmap, this tool helps you make a clear, defensible technology decision — based on where your competitive advantage actually lives, not on instinct or budget pressure.

Step 1 — Locate your competitive advantage. For the capability you’re assessing, ask: is the way we do this genuinely different from how our competitors do it — and does that difference matter to our customers? If yes, this is a source of competitive advantage. If a competitor could buy the same off-the-shelf tool and match you, it probably isn’t.

Step 2 — Assess the options honestly.

• Buy off-the-shelf when the process is generic — accounting, payroll, basic CRM. These are solved problems. Use the market’s solutions.
• Build custom when the process is the source of your advantage — when what makes you different is precisely the thing that off-the-shelf would flatten.
• Use a hybrid when neither extreme is right — off-the-shelf infrastructure for the commodity parts, a custom layer for the proprietary logic.

Step 3 — Map to the nucleus. Where does this capability sit in your organisation’s nucleus model? Core expert knowledge should almost always be custom. Generic infrastructure almost never should be. The hybrid cases live in between.

Step 4 — Make the call. State your decision, the primary reason for it, and what would change it. Having a rationale you can articulate prevents the decision drifting when circumstances shift.

Want to go deeper?
The online version of this tool includes a full technology options assessment matrix, a guide to evaluating specific platform categories (CRM, workflow, data, AI tools), and a worked example of the nucleus model applied to a professional services business.
Available in the members area at [website]