Build, Buy, Improve, or Integrate?

Before choosing a technology solution, make sure you understand the problem you're actually trying to solve.

Organizations often approach technology decisions as if there are only two choices: buy something or build something.

But frequently, neither is the best answer.

Sometimes the organization already owns the right technology - it just isn't configured properly.

Sometimes two perfectly capable systems need to exchange information.

Sometimes the problem isn't the software at all.

Sometimes a small custom tool could solve a very specific gap without replacing an entire enterprise system.

And sometimes, yes, the organization has genuinely outgrown what it has and needs something new.

The hard part isn't finding technology. It's determining which kind of solution the problem actually requires.

Start with the problem, not the product

Someone attends a conference. Sees a demonstration. Hears about a new platform. Discovers what another company is using. Reads about AI. A vendor gives an impressive presentation.

Suddenly the conversation becomes: “Could we use this?”

Maybe. But that's not the first question.

The first question is: “What are we trying to make better?”

Once a product enters the conversation, something subtle can happen. We start viewing the problem through the capabilities of that product.

Instead of defining what the organization needs and then evaluating possible solutions, we begin asking how our organization could fit into what the technology does.

Sometimes that's appropriate. Sometimes it's how organizations end up with very expensive software that solves 72% of the problem while creating three new ones.

Understand what better looks like

Before evaluating technology, describe the desired outcome. Not the software. The outcome.

Maybe employees currently enter the same information into three systems. The goal isn't necessarily “We need a new system.” The goal might be: Information should be entered once and reliably available everywhere it is needed.

Maybe managers spend hours assembling reports. The goal isn't “We need better reporting software.” Perhaps it's: Managers should have accurate information available when they need to make decisions.

Maybe customers call because they can't see the status of their requests. The goal isn't necessarily “We need a customer portal.” It's: Customers should be able to easily understand what is happening without having to call us.

Once we define the desired outcome, we have considerably more freedom in how we achieve it.

1. Improve what you already have

This option is frequently overlooked.

Organizations can spend years using sophisticated technology while taking advantage of a surprisingly small percentage of what it can do.

Sometimes the feature already exists. Sometimes the system needs better configuration. And sometimes the problem goes all the way back to implementation.

Go-live has a way of becoming the finish line

Large implementations are demanding. Deadlines are approaching. Budgets are being watched. Employees need to be trained. Data has to be converted. Interfaces have to work. Testing has to be completed.

As go-live approaches, priorities naturally shift toward one objective: Make it work.

Nice-to-have improvements get moved to a list. A cumbersome workflow is accepted temporarily. Reporting will be refined later. That manual step will be automated in Phase 2.

The team knows the implementation isn't exactly where they ultimately want it to be, but everyone agrees: “We'll come back and clean that up after go-live.”

Then everyone crosses the finish line. The implementation team moves on. Consultants leave. Project meetings disappear from calendars. Employees return their attention to the work that accumulated while they were implementing the system.

And Phase 2? Sometimes Phase 2 never comes.

The temporary workaround becomes the permanent process. The configuration decision made simply to get through implementation becomes “how the system works.” Five years later, employees may not even know there was supposed to be another phase.

Go-live measures whether the project launched. The better question is whether the organization got the outcome it was trying to create.

And sometimes the organization outgrows its own configuration

Even a well-designed implementation captures the organization at a particular moment in time.

How many employees did you have? How many locations? Which products did you sell? How was the organization structured? What did customers expect? Which regulations applied? How complex were operations? Which systems existed? How did information move? Who made which decisions?

Those answers shaped how the technology was configured.

Then the organization changed. It grew. Added locations. Entered new markets. Acquired another company. Changed its organizational structure. Added products or services. Created new departments. Adopted new technology. Changed policies. Encountered new regulations. Or simply became more complicated.

But sometimes the system configuration barely moved.

People compensated instead. They created spreadsheets. Added manual steps. Developed exceptions. Changed procedures around the technology. Built new systems alongside the old one.

Eventually someone concludes: “This system doesn't work for us anymore.”

Maybe. But there's another possibility worth investigating:

The system may still fit the organization. The configuration may fit an organization that no longer exists.

Before replacing it, rediscover it

Technology changes too. The software you implemented six years ago isn't necessarily the software available today.

Vendors add capabilities. Integrations improve. APIs become available. Automation expands. Reporting gets better. Features that required customization years ago may now be standard.

Meanwhile, your own organization has accumulated years of experience about what works and what doesn't.

Ask: If we were implementing this system today, knowing what we know now, would we configure it the same way?

What did we postpone during the original implementation? Which temporary workarounds became permanent? What capabilities have been added since we implemented it? Where has our business changed? Which configuration decisions no longer reflect reality? What manual processes have grown around the system? What are employees doing outside the technology to make the technology work?

Could we get significantly more value from something we're already paying for?

Sometimes the answer will be no. The organization truly has outgrown the technology. Fine. Then replace it.

But at least now we're replacing it because we've determined the technology itself is the constraint, rather than assuming replacement is the answer because an old configuration no longer works particularly well.

Go-live isn't the end of implementation. It's the beginning of living with what you implemented.

2. Integrate what already works

Sometimes the systems aren't the problem. The spaces between them are.

One system knows the employee. Another knows the schedule. Another knows the time worked. Another processes payroll. Another records the financial result.

Each may do its job very well. But if people are manually carrying information between them, the organization hasn't really created a technology ecosystem. It has created several islands. And employees have become the bridges.

Before replacing one of those systems, ask: What if they simply talked to each other?

An integration may allow information already known in one place to flow reliably to another. That can eliminate duplicate entry, reduce interpretation, improve consistency, accelerate processes, and preserve investments in systems that work well.

Sometimes the best technology project isn't replacing anything. It's connecting what you already have.

3. Buy something

Sometimes the answer really is a new product.

There is mature technology available. It solves the problem well. The organization's needs aren't unusually unique. The vendor can support it. The economics make sense. And buying it is far more sensible than recreating something the market has already solved thousands of times.

Great. Buy it.

But evaluate it against the outcome you defined before you saw the demo.

Can it support the actual business rules? Can it handle the exceptions? Does it integrate with the systems that matter? Can employees realistically use it? What happens to the data? How configurable is it? What will implementation require? What will it cost to maintain?

And importantly: What will the organization have to change to accommodate the technology?

Every system requires some adaptation. That's normal. But understand the tradeoff before signing the contract.

4. Build something

And sometimes what you need simply doesn't exist.

Or what exists solves far more than you need at a price that makes no sense. Or your process genuinely creates competitive advantage. Or there's a small but important gap between systems that would be cumbersome to solve with another large platform.

Custom development doesn't have to mean: “Let's build our own ERP.”

Sometimes building means a focused application, a workflow, an interface, a dashboard, an automation, or a small tool that handles one specific organizational need exceptionally well.

The advantage of custom development is obvious: It can fit the organization.

The disadvantage is equally important: You own it.

Someone has to maintain it, secure it, document it, update it, support it, and adapt it when requirements change.

Custom technology should solve a problem valuable enough to justify that responsibility.

And sometimes the answer is more than one

The best solution may be Improve + Integrate: configure the existing platform properly, then connect it to Finance.

Or Buy + Integrate: purchase the best specialized product, but ensure information moves seamlessly into the rest of the organization.

Or Improve + Build: keep the core enterprise system and build a simple interface that makes a difficult process dramatically easier for employees.

Or perhaps: Stop doing it.

Because before spending six months and a large amount of money automating something, it's worth asking whether the process still needs to exist.

Don't evaluate technology in a silo

A system rarely affects only the department buying it.

HR chooses something that affects Payroll. Operations chooses something that affects Finance. Finance changes something that affects reporting. Technology inherits responsibility for supporting all of it. Employees experience the workflow. Leadership consumes the resulting information. Customers may experience the outcome.

This is why technology selection isn't only a technology decision. It's an organizational design decision.

The right people need to be in the conversation - not necessarily in every meeting and not to make every decision by committee, but enough to understand what information goes in, what comes out, who depends on it, what happens upstream and downstream, which business rules matter, and what the change could unintentionally break.

A solution that works beautifully for one department and creates three new manual processes elsewhere isn't really an improvement. It has simply relocated the work.

Look at the total cost of complexity

Price matters. But purchase price is only one cost.

There is implementation, integration, training, configuration, data migration, support, maintenance, upgrades, change management, internal administration, and the time employees spend compensating for whatever the solution doesn't do well.

Sometimes the cheaper product creates the more expensive organization.

Sometimes the expensive platform eliminates five other tools and becomes the better investment.

Sometimes custom development looks expensive until you calculate the annual cost of the manual work it replaces.

And sometimes the smartest decision is to spend almost nothing and fix the process.

Technology economics make more sense when you evaluate the whole system around the technology.

Don't automate a bad process

Technology can make a good process faster. It can also make a terrible process faster.

If a workflow contains unnecessary approvals, duplicate information, outdated requirements, confusing responsibilities, and six steps nobody can explain, automating all six steps isn't necessarily transformation. It's just faster confusion.

Before digitizing a process: understand it, challenge it, simplify it, decide what actually needs to happen, then determine where technology adds value.

This is why process and technology strategy belong together.

The best answer isn't the most impressive one

Sometimes the answer is a sophisticated new platform. Sometimes it's custom development. Sometimes it's an integration. Sometimes it's changing three configuration settings in software you've owned for six years.

The objective isn't to select the most technologically impressive solution. It's to find the solution that creates the best outcome for the organization.

The best technology is not necessarily the newest, biggest, or most sophisticated. It's the technology that makes the organization work better.

A question worth asking

The next time someone says, “We need a new system,” don't immediately disagree. But don't immediately start shopping either.

What are we trying to make better?

Define the outcome. Understand the work. Listen to the people who experience it. Follow the data. Look across departments.

Can we improve what we have?

Should we integrate what already works?

Is there something we should buy?

Is there something worth building?

Should we stop doing this altogether?

Problem first. Technology second.