Consumer
The team that depends on a behaviour. They need a failing check when that behaviour moves, without calling the other service.
Software with a boundary the build can hold.
We design and build applications, APIs, and the seam between teams. A change should fail in the build when that promise moves, without calling the other system.
The boundary, drawn.
Consumer, promise, provider. The middle is what the build is allowed to enforce.
Contract
The promise in a form both sides can version. REST, GraphQL, or an event. The shape follows the constraint.
Provider
The team that owns the behaviour. They see the break in their build, before a journey discovers it.
A boundary drawn for the explanation.
What we leave behind.
The offer is the boundary and the check. Pact, OpenAPI, and a schema registry are examples of how a promise can be held. They are not the service.
A named boundary
Who owns each side, and which changes are allowed to cross.
A check in the build
The promise fails locally and in CI, with seeded data instead of a living dependency.
A team that can extend it
The first version is not a specialist's private tool. The next contract is yours to add.
The edge of the work.
Said before a proposal, so the engagement has a shape.
We will
Design the boundary, the checks, and the path into CI so the team can keep it.
We might
Build the first version beside your engineers once the design is agreed.
We will not
Treat a framework migration as a strategy, or staff a team you do not intend to lead.
Questions we expect.
Is this only test doubles?
No. The page is about boundaries you can change without a live dependency for every check.
Do you build the whole product?
End-to-end delivery is one engagement shape. Embedded consulting is another. The first conversation picks which.
Name the dependency you are waiting on.
That queue is usually a missing contract. We can confirm that in a short conversation.