Nothing Ships Until It Passes the Fortify Gate

Last Friday, a feature did not ship.

The code was written. The tests passed. The PR had two approvals. The client had seen the demo on Wednesday and liked it. The team was ready to deploy before the end of the day, which, on a small team moving fast, is what Fridays often look like.

Ten minutes before the deploy, someone pulled up the Fortify Gate checklist. One of the items was "rollback executed end-to-end in staging, under five minutes, with no data loss." The team had a rollback script. Nobody had actually run it against a realistic data set. Which meant that if the feature broke in production on a Friday afternoon, the team had a plan that might or might not work, and no way to know which.

The feature did not ship.

It went out the following Tuesday, after the rollback got tested properly and one of its steps was rewritten because it turned out to take eleven minutes, not five. The client barely noticed the delay. The team caught what would have been, on a previous engagement, a Monday-morning fire drill.

This is the kind of thing the Fortify Gate is for.

Why "done" is the most dangerous word on a small team

If you read the $50k Prototype Trap piece from Series 1, you already know where this goes.

Every founder and technical lead I have worked with has, at some point, had a conversation about whether a feature was "done." The designer thinks it is done when it looks right. The developer thinks it is done when the tests pass. The founder thinks it is done when the demo plays. The customer thinks it is done when the thing works, reliably, every time, even when the network is bad and the data is weird.

On a traditional team, this disagreement surfaced slowly. Someone would build for a week. Someone would review for three days. QA would bang on it for another two. In the friction of those handoffs, four versions of "done" would get negotiated into a shared one. It was inefficient. It was also, accidentally, a safety mechanism.

In the AI era, that negotiation time has collapsed. Features get written in hours. PRs get approved in minutes. The friction that used to catch the gaps is gone.

What looks done on Wednesday can be in production on Thursday, and nobody in the room has stopped to ask whether the four versions of "done" actually got reconciled.

The Fortify Gate is the mechanism we built to reconcile them. Not in a meeting. In a checklist.

What the Fortify Gate actually is

The Fortify Gate is a short, written list of conditions that have to be true before a release ships. It sits next to the PR template. It takes about ten minutes to run. If any item fails, the release does not go live. That is the whole mechanism.

There are four categories, tuned for a three-to-five person team.

The first is rollback, and it is the one teams cheat on most. A rollback plan is not a section of a wiki. It is a script that has been executed against realistic data, within a defined time, with no data loss. "We could revert the commit" is not a rollback plan. "We ran the rollback in staging yesterday, it took four minutes, and we have the log" is. The difference between those two sentences is the difference between a team that will be fine on a bad Tuesday and a team that will not.

The second is known failure modes. Before a feature ships, someone has to write down the two or three ways this is most likely to break in production, and how the team will know when it does. Not every possible failure. The realistic ones, with the specific signals that would fire.

If you cannot name them, you have not thought about the release carefully enough to ship it.

The third is telemetry. The feature cannot go live until the measurement that will tell you whether it worked is already in place. Not a plan to add it later. Live. This is the item that, more than any other, separates products from prototypes.

A prototype ships and hopes. A product ships and knows.

The fourth is ownership. A single name goes on every release. Not a team, not a channel, not a rotation. One person who is on the line if the release breaks in the next seventy-two hours. Small teams sometimes resist this, because it feels like blame assignment. It is not. It is the accountability that makes the other three items actually get done.

Ten checkboxes, total. One page. No ceremony.

The conversation nobody wants to have

Here is the part of this that sounds harder than it is.

The first time a team runs a Fortify Gate and something fails it, there is a conversation with a client or a stakeholder that nobody enjoys. It usually sounds like: "We said we would ship this Friday. We are not shipping it Friday, because the rollback is not tested." The first time you have this conversation, it feels expensive. Everyone in the room wonders whether you are being too cautious.

The second time, it feels less expensive. By the fourth or fifth time, something interesting happens: the client stops being surprised, and starts expecting it. The conversation shifts from "why are you slowing us down" to "what failed the gate, and what do we need to do to get it through."

That shift is the whole point.

On the engagements where the Fortify Gate is running, "when will it ship" stops being a vibe check and starts being a question with a real answer. "It ships when it passes the gate" is a statement I can stand behind in front of a client, without hedging, because "pass the gate" is a defined thing, not a judgment call I will have to defend later.

That is worth more than almost any other planning artifact we produce.

It turns "done" from a word that four people in the room are each defining differently into a word that means one thing. And the thing it means is evidenced, not asserted.

What we are still calibrating

In the spirit of building in public: the Fortify Gate catches the obvious stuff cleanly. Missing rollback plans, absent telemetry, anonymous releases with no owner. Where we are still tuning is the threshold for "how much telemetry is enough" on lower-risk features. Over-index and the gate starts slowing down low-stakes work. Under-index and you learn two weeks later that nobody actually knows whether the feature gets used.

The early signal from our live client teams is that the gate's biggest value is not the catches. It is the fights it prevents.

The awkward Friday-afternoon negotiations about whether to ship something that is probably fine. The Monday-morning retrospectives about why a rollback took forty minutes instead of five. Those do not happen now, because the decisions they force got made earlier, in the ten minutes it takes to run the checklist.

Next week, Chuck and I close the series with three months of honest retrospective: what is working, what is not, and what we would tell a team starting on CRAFT today. It is the first article in this series that is not about a specific artifact. It is about what happens when you run the whole system on real engagements, with real stakes, for long enough to know.

The Take-Home: The Fortify Gate Checklist

One page. Tuned for a three-to-five person team. Put it in your repo next to the PR template. No release ships until every box is checked, or the team has an explicit, recorded exception with a named owner and a follow-up task.

Fortify Gate: [Release Name]

Release owner: [One name. Accountable for next 72 hours.]

Target ship date: [YYYY-MM-DD]

Related Intent Contract: [link]

## Rollback

• Rollback procedure is documented in the repo, not a side doc.
• Rollback has been executed end-to-end in staging against realistic data within the last 7 days.
• Rollback completes within the team's defined SLA (e.g., 5 minutes).
• Rollback has been verified to preserve customer data with no loss.

## Known Failure Modes

• Two or three most likely failure modes are written down in the release notes.
• Each has a specific signal or alert that would fire if it occurs.
• The release owner has confirmed they will see those signals in real time.

## Telemetry

• The outcome metric from the Intent Contract is instrumented and live before release.
• Baseline for that metric is recorded prior to ship.
• Post-release telemetry review is scheduled for day 1, day 7, and day 30.

## Ownership

• A single named owner is on the line for the next 72 hours.
• That owner has acknowledged the ownership in writing (not verbally).

## Exceptions

• Any unchecked box above has a written exception, signed off by the release owner, with a named follow-up task and a due date.

Run it. If you cannot pass it honestly, do not ship. The release that waits three days costs far less than the release that fails in production without a rollback.

If this resonated, subscribe. We're writing about what's actually changing in software delivery, no hype, no hand-waving, just what we're seeing on real projects.