Why would a software vendor publish a test for replacing them?

Because the alternative claim is unverifiable. Every supplier says it builds transferable systems, and a buyer has no way to check that before signing. Publishing the checks is the only version of the claim that carries weight. A supplier that is hard to replace earns more in the short term, which is exactly why willingness to be measured on replaceability tells you something the sales conversation cannot.

When should we run these checks?

Twice. During evaluation, ask each shortlisted supplier how they would evidence each of the four - the answers separate suppliers quickly and cost you nothing. Then again roughly ninety days after go-live, while the original team is still available to close any gaps. Running them for the first time during an exit is running them too late.

Does passing this test mean the product is good?

No. It means the product is operable and transferable. A well-handed-over product can still solve the wrong problem. These four checks measure whether you own what was built; whether it was worth building is a separate question, answered by whether the metric you agreed at the start actually moved.

Our current system fails most of these. What now?

That is common and it is recoverable, and it is worth separating the four. The deployment and runbook gaps are usually days of work rather than a rebuild. An admin surface that cannot correct data is a scoping problem and costs more. The order that pays back fastest is normally deployment first, because it unblocks every other supplier you might bring in, then the runbook, then the admin gaps in the order your team hits them.

Do you apply this to your own engagements?

These are the checks we would rather be judged on, and we will walk through them for work we have delivered. We would not claim every engagement has passed all four on day one - handover quality varies with how a project was scoped and what a client chose to prioritise, and a supplier claiming a perfect record here is telling you something you cannot verify. Ask us for specifics on the engagement type closest to yours.

Why would a software vendor publish a test for replacing them?

Because the alternative claim is unverifiable. Every supplier says it builds transferable systems, and a buyer has no way to check that before signing. Publishing the checks is the only version of the claim that carries weight. A supplier that is hard to replace earns more in the short term, which is exactly why willingness to be measured on replaceability tells you something the sales conversation cannot.

When should we run these checks?

Twice. During evaluation, ask each shortlisted supplier how they would evidence each of the four - the answers separate suppliers quickly and cost you nothing. Then again roughly ninety days after go-live, while the original team is still available to close any gaps. Running them for the first time during an exit is running them too late.

Does passing this test mean the product is good?

No. It means the product is operable and transferable. A well-handed-over product can still solve the wrong problem. These four checks measure whether you own what was built; whether it was worth building is a separate question, answered by whether the metric you agreed at the start actually moved.

Our current system fails most of these. What now?

That is common and it is recoverable, and it is worth separating the four. The deployment and runbook gaps are usually days of work rather than a rebuild. An admin surface that cannot correct data is a scoping problem and costs more. The order that pays back fastest is normally deployment first, because it unblocks every other supplier you might bring in, then the runbook, then the admin gaps in the order your team hits them.

Do you apply this to your own engagements?

These are the checks we would rather be judged on, and we will walk through them for work we have delivered. We would not claim every engagement has passed all four on day one - handover quality varies with how a project was scoped and what a client chose to prioritise, and a supplier claiming a perfect record here is telling you something you cannot verify. Ask us for specifics on the engagement type closest to yours.

Product Engineering

Can you run the product without the vendor?

Four checks that separate a product partner from a development contract. Run them against every supplier on your shortlist, including us.

Talk to us Product engineering

Trusted by 500+ Clients

The Moweb Exit Test: what it is

The Moweb Exit Test is a four-part check that establishes whether a delivered software product can be operated, changed and recovered by the organisation that owns it, without the supplier who built it. Developed at Moweb Technologies from eighteen years of handovers, it is run against a shortlist of suppliers before signing, and a product passes only if all four hold: a second supplier can deploy it from a clean machine; a non-engineer can make a routine change; the admin surface runs the business rather than only reporting on it; and a runbook exists for the failures that should be expected.

Every supplier says the same thing. These four are checkable.

“Product partner, not a body shop” appears on the site of almost every development supplier, including ours. It is not a claim a buyer can verify before signing, which makes it worth roughly nothing at the point it matters.

These four checks are verifiable, and they share a property worth noticing: a supplier that fails them is more expensive to leave, and therefore earns more. Any supplier willing to be measured on them is telling you something the sales conversation cannot.

The test

an afternoon Four checks, run in.

None of these needs a technical audit or access to source code. Each is something you or a colleague can attempt directly.

A second supplier can deploy it from a clean machine

How to run it. Give the repository and its documentation to an engineer who has never seen the project, on a laptop with nothing installed, and ask them to get it running.

Passes

They reach a running local environment by following written steps, and any credential they need is named and requestable.

Fails

It only builds on a machine someone configured by hand, steps live in a person's memory, or a required key exists in one engineer's environment and nowhere else.

Why it matters. This is the single check most likely to fail quietly, because everything works fine as long as the original team is still there. It is also the check that decides whether you are choosing to stay with a supplier or unable to leave.

A non-engineer can make a routine change

How to run it. Ask a member of your own team, without development skills, to change a price, publish a page, add a user, or update a piece of content in production.

Passes

They do it through an interface, unassisted, and the change takes effect without a release.

Fails

Routine changes require a ticket, a developer, and a deployment.

Why it matters. Where routine change requires engineering, every small business decision is priced and queued by a third party. The cost shows up as delay and dependency long before it shows up on an invoice.

The admin surface runs the business, not just reports on it

How to run it. Take the five operational tasks your team performs most often and try to complete each one in the admin interface.

Passes

The admin can create, correct and reverse the things that matter, including the awkward ones: refunds, re-issues, permission changes, correcting a record entered wrong.

Fails

The admin is read-only dashboards, and anything corrective needs a database change by the supplier.

Why it matters. A reporting surface with no corrective actions means every real-world exception becomes a support request. This is the most common gap in products that were scoped by feature list rather than by how the business actually operates.

A runbook exists for the failures you should expect

How to run it. Ask for the written procedure covering the three most likely production failures, and check when it was last verified against the running system.

Passes

The procedure names symptoms, first response, who to escalate to, and how to confirm recovery, and someone has followed it recently.

Fails

There is an architecture diagram and a support email address.

Why it matters. The question is not whether a supplier can fix an outage. It is whether you can survive one at 2am while you wait for them, and whether you would know the difference between a degraded system and a broken one.

What the four have in common

None of them asks whether the code is good. They ask whether the knowledge needed to operate the product exists outside the heads of the people who built it. That is the difference the word “partner” is meant to carry, and it is the only part of it a buyer can confirm.

How we approach product engineering

Common questions

About the exit test.

Including the obvious one about why a supplier would publish this.

Because the alternative claim is unverifiable. Every supplier says it builds transferable systems, and a buyer has no way to check that before signing. Publishing the checks is the only version of the claim that carries weight. A supplier that is hard to replace earns more in the short term, which is exactly why willingness to be measured on replaceability tells you something the sales conversation cannot.

Proof

Work we have shipped.

All case studies

Financial ServicesDebt Recovery IntelligenceScoring and prioritisation for a debt recovery operation, so collection effort is aimed at the accounts where it will actually land. The client has asked not to be named, and no performance figures are published.Read the study Conversational AIAI Knowledge AssistantA proof of concept pairing a chat interface with retrieval over a private knowledge base, so answers are grounded in the client's material rather than in model training data. The client has asked not to be named.Read the study Supply ChainWarehouse & Routing IntelligenceWarehouse and distribution intelligence covering route optimisation and demand prediction. The client has asked not to be named, and no performance figures are published.Read the study

Work with us

Ask us how we would evidence all four.

Tell us what you are building or what you have inherited, and we will walk through how each check would be met on an engagement like yours - including where it would be hard.

Talk to an engineer See the work

ISO 27001:2022

Information security

CMMI Level 3

Engineering process

1 business day reply

Senior engineer reads first