Most outages I have seen in small systems don't come from a clever bug. They come from two pieces of software disagreeing about what a request looks like for a few minutes during a release. One side has shipped the new shape, the other hasn't yet, and every call in between fails.

At Orivox we build an AI website editor, and our system is split in exactly the way that makes this risk real. This post is about the one release rule we use to keep that split from hurting us: a change to the contract between our services is made additive first, released, and only then used.

The split

Orivox is two codebases running as four processes. The web app handles accounts, credits, publishing and domains, and it has its own job worker. The editing service runs the AI edit loop, keeps each project's Git history and the chat transcript, and has its own worker too. They share one Postgres database and one Redis, but they talk to each other only over HTTP.

That HTTP boundary is the contract. When an owner types a request, the web app checks the account, queues the turn, takes the project lock and sends the editing service the latest message. The editing service holds the full conversation, so the web app only ever sends the newest turn. A third client uses the same boundary: our remote MCP server, which lets an owner edit their site from their own Claude, calls the editing service and the web app over HTTP and holds no database write credentials of its own.

So there are several callers and two services, released separately. Each service can be switched between our two production servers on its own, which means one can be released or rolled back without touching the other. That independence is a feature. It also means that, at any given moment, the two sides of the contract may be running different versions.

Why "deploy both at once" is not a plan

The tempting answer is to ship both services together. In practice "together" is never instant. Releases go to a standby server first and are checked there before they take a single customer request. Traffic moves when the check passes, and rolling back means moving traffic back. Any of those steps can happen to one service and not yet the other.

If a contract change only works when both sides move in the same second, then every release window, every standby check and every rollback becomes a moment where the system is broken. We wanted the opposite: every state the system can be in during a release should be a working state.

The rule: add, release, then use

The rule has three steps, and the order matters.

1. Make the change additive. The new version of the contract has to accept everything the old one accepted. A new field is optional. A new endpoint sits next to the old one. Nothing that an existing caller sends stops working, and nothing an existing caller reads disappears.

2. Release the side being called first. Our release order follows the dependency: the editing service first, then the web app that calls it. Once the editing service understands both the old and the new shape, it doesn't matter which web app version is talking to it.

3. Only then start using it. The caller begins sending the new shape after the callee that understands it is live. If the caller has to roll back, it simply goes back to the old shape, which the callee still accepts.

Removing the old shape, if it ever happens, is a separate and later change, made only once nothing sends it any more.

Here is the same idea as a table of the states a release can pass through:

There is no row where the system is down, and that is the whole point.

Pinning the contract with tests on both sides

An agreement that lives in people's heads is lost by the next refactor. The contracts between our services are pinned by tests on both sides, so the caller's idea of the request and the callee's idea of it are checked separately. The same habit runs through the rest of the system: every live failure becomes a replay test, so a fix cannot quietly disappear in a later change.

A test on one side only catches half the problem: the callee test proves it still accepts what it promised, and the caller test proves it still sends what the callee expects.

How it fits with the rest of the release process

The additive rule only works because the rest of the release path is boring on purpose:

• Code never changes on a production server by hand. It is pushed to the repository, pulled into a development environment with its own copy of both services, verified there, and promoted to production from an admin dashboard that records every release and keeps a backup of what it replaced.
• Services restart only when we release. Operating-system updates don't bounce the application on their own schedule, so a contract change never meets an unplanned restart halfway through.
• We confirm what is deployed by its content. A release is checked by hashing the files actually running, not by trusting a version label. When you depend on knowing which side of a contract is live, that matters.
• The AI connector keeps no session state. Any instance of the MCP server can serve any request, so a restart costs at most the one request in flight.

What this buys a small team

None of this is new. It is the classic expand-then-contract approach larger teams use for schemas and public APIs. It matters just as much with two internal services: we have no release manager, so the order of operations is the coordination.

Practically, it gives us three things. Either service can be released on its own. A rollback of one side never strands the other. And the people using the product, owners editing their sites in chat or from their own AI, never see a half-released state.

If you are splitting a product into two services, my advice is to write the rule down before the first contract change, not after the first outage: add first, release the callee first, use it last, and test the boundary from both sides.

You can see the product this architecture runs here: https://www.orivox.pro/

Disclosure: I'm the founder of Orivox, and this post describes our own system.