Do we need middleware?

Sometimes. Native connectors first, established middleware second, custom code last. Each step up costs more to build and considerably more to maintain, so we only climb when there's a reason.

What happens when a platform changes its API?

It will, and that's precisely why an unmaintained integration is a liability. Under Champion1 we handle it as part of the fee. On a project basis, we document what to watch for.

Can you integrate with our custom software?

Yes. Custom and legacy systems are a large part of what we work with, including ones with no documented API where we have to work out the interface ourselves.

How do we know it's working?

Monitoring and alerting are part of the build. The failure mode that costs real money isn't an integration breaking — it's an integration breaking quietly.

AliveCommerce / Capabilities / Connect systems that don't talk

Connect systems that don't talk

An export, an import, and a spreadsheet in between. It works, it has worked for years, and it depends entirely on somebody remembering to do it on Tuesday. Every manual handoff is an outage waiting for a holiday.

Does this sound like you?

Tick what applies. The count changes what we'd recommend, and sometimes the recommendation is to do nothing yet.

What's actually causing it.

Almost never carelessness. Usually the predictable result of a decision that made sense at the time.

Each system was chosen on its own merits

Correctly, at the time. Nobody bought an ERP by evaluating how it would talk to a field service app that didn't exist yet.

Integration was treated as a one-off

Built during an implementation, then unowned. APIs change, credentials expire, and silent failures accumulate because nobody is watching for them.

The middle got filled by a person

A manual bridge is cheap to start and invisible in the budget, so it never gets escalated. It only becomes visible when that person is away.

What we do about it.

In this order, because doing them out of order is how these projects fail.

Work out what actually needs to move

Not everything does. Most integration projects are larger than they need to be because nobody questioned whether a field was genuinely required on both sides.

Use what the platforms give you

Native connectors and established middleware before custom code. Cheaper to build, far cheaper to maintain, and easier for someone else to pick up.

Build for failure, not just success

Integrations break. What matters is whether anyone finds out. Monitoring, alerting and a documented recovery path are part of the work, not extras.

Leave it maintainable

Documented, monitored, and owned by someone — whether that's your team or ours. An unowned integration is a future outage with a date on it.

Typical first phase

3 to 8 weeks

One integration, built and monitored

Cheaper than you'd think

Native first

Custom code is the last resort, not the default

Most common trigger

A silent failure

Discovered weeks after it started

Which way in.

Same team either way. The difference is whether this has an ending.

A defined project

AliveCommerce

Integrations scoped and priced up front, built on native connectors where possible and custom where necessary. Fixed Budget, Scope Controlled.

Integrations

Continuous ownership

Champion1

When integrations need watching rather than just building. We monitor them, fix them when platforms change underneath, and add new ones as you need them.

See Champion1

What it looks like in practice.

Industrial supply · 45 staff · ongoing

Store and ERP inventory drifted daily

A nightly export nobody was checking. We replaced it with a monitored integration and, more usefully, an alert when it stops.

Live

instead of nightly

Straight answers.

Related.

These tend to travel together.

Reduce manual work“The same data gets typed into three systems.”See the numbers sooner“Month-end takes a week to assemble by hand.”Sell to customers online“Contract pricing and stock levels don't survive the handoff.”

Tell us what's breaking.

We'll tell you which part of this we'd put on it, roughly what it costs, and whether it's worth doing at all — including when the honest answer is that you don't need us.

Start the Conversation

Knowledge and process

Applications and data

Customer and web

Browse by symptom instead

The structure

Continuous ownership

Before you commit

Start with one problem

Priority sectors

Also

Or by situation

Not sure you fit?

Reading

Most read

Proof

Nobody owns the application layer