You have run consumer-driven contract testing across 60 services for two years. The finance director asks whether it is still worth what it costs. How do you answer, and what would make you recommend stopping?

What the interviewer is testing

Whether you can evaluate a practice you own. Most candidates defend contract testing on principle, which tells the interviewer nothing except that they have read about it. The answer they are looking for names the evidence that would change your mind, and knows what the practice costs.

The clarifying questions that change the answer

• How often does a provider change in a way a consumer depends on? If provider APIs are versioned and additive by policy, breaks are rare by construction, and contract tests are guarding a door nobody walks through.
• What is the cost of an integration break today — a rolled-back deploy, or a failed payment run discovered by a customer? This sets the value of prevention.
• Where is verification run, and against what? A provider verified against contracts from consumers that were deleted a year ago is doing archaeology.
• What was the alternative before it? If it replaced a shared integration environment, the comparison is against that environment's cost, not against zero.

A strong answer's arc

Answer with numbers you already collect, or say plainly that you do not collect them and that this is the first finding.

The metric that settles it: how many provider builds were stopped by a contract failure that represented a real break, over the period, and what each of those would have cost in production. Against that, the running cost, which for an estate this size is typically 300-600 minutes of CI a day plus the broker's operation, and the engineer-time spent on contracts that failed for reasons that were not real breaks. Two years is enough history to answer this: if fewer than a handful of genuine breaks were stopped, the practice is being paid for in production capacity and attention without returning anything.

Then the decomposition, because "is it worth it" is rarely a single answer across 60 services. Contract testing earns its keep between independently deployed services with a small number of known consumers, and you should prefer it there because the alternative, a shared integration environment, fails in a way that is far more expensive: one broken service blocks every team. It earns much less for a provider with one consumer deployed in the same pipeline — a single integration test is simpler — and it does not work at all for a public API with unknown consumers, where the equivalent is versioning, deprecation policy and usage analytics on which fields are actually read.

Common weak answers

• "It catches breaking changes." So does a shared environment, a canary, and a customer. The question is cost per break caught, and how early.
• "We can't remove it, the teams rely on it." Reliance is the thing being evaluated. If the contracts have not failed usefully in eighteen months, the reliance is on a ritual.
• Defending the tooling. The finance director is not asking about Pact. Answering with tool features signals you have confused the practice with its implementation.

What a strong answer adds

The stale-contract problem, unprompted: verification against every contract ever recorded grows without bound, so contracts need an expiry tied to whether the consumer version is still deployed. Without it, providers are blocked by consumers that no longer exist, which is how the practice acquires its reputation for friction.

And the recommendation, stated as a decision rule rather than a preference: keep it where a provider has between two and roughly twenty known internal consumers on independent deployment schedules; replace it with a single integration test below that; replace it with versioning and field-level usage telemetry above it. Offering to stop something you built is the part that makes the rest credible.