An aviation-property practice lives on its software the way a hangar lives on its doors: listing engines, viewing schedulers, booking portals, tenant dashboards, commission calculators. When a vendor changes how any of those behave — new quote logic, a reshaped booking flow, an altered commission display — the consequences land on your clients and your commission statements, never on the vendor’s roadmap slide. Yet almost nobody audits vendors for release discipline before signing, even though the Ops Atlas has organised this exact question into a teachable practice it files under ReleaseOps: the strategy layer that separates what gets installed from what gets experienced by clients. Below is an audit you can send to a vendor this week, five sections long, each naming the specific evidence to request and the answers that should reassure you. Vendors with good answers deserve an untroubled renewal; vendors without them deserve a formal conversation, with this document attached.
Why ReleaseOps belongs in vendor due diligence
Standard software procurement asks about features, uptime percentages and price, then stops precisely at the point where incidents actually begin. The gap between what a vendor installs and what its users come to experience is where the vendor’s real operational maturity lives — can they ship a change to a tenth of their tenants first, withdraw a misbehaving quote rule within seconds, and show you a record of who saw what, and when? The Atlas’s material hands you the vocabulary to ask these questions without an engineering degree, and the shape of the vendor’s answers will tell you more than three reference calls.
Section 1: The split itself
Ask the vendor to describe, in writing, how they keep installation apart from exposure. Evidence to request: one example change that reached a single customer segment before the rest, with the dates attached. What good looks like: a crisp written answer naming staged or gradual exposure, feature switches or comparable controls, and a standing policy for announcing changes to clients. What bad looks like: confusion between “deployment” and “release”, or a claim that everything ships to everyone simultaneously because that is simply how the platform works. In the second case, every quote, viewing slot and commission display your practice relies on is hostage to a release calendar you cannot see and cannot influence.
Section 2: Exposure records
Ask which users saw which behaviour, on which dates, and where that record is kept. Evidence to request: a sample exposure log or a change-announcement trail drawn from a real, redacted release. The Atlas treats exposure as a decision, and decisions generate records; a vendor unable to produce them is either not making those decisions at all or not keeping the memory of them — and both dispositions cost you eventually. For a regulated practice, those records are also the entire difference between explaining an incident to a client calmly and guessing about one in writing.
Section 3: Gates and overrides
Ask what stops a change when one of its checks fails, and precisely who holds the power to overrule the block. The Atlas standard: every gate declares an effect — block, hold, or record — and any human bypass carries a name and an expiry date. Evidence to request: the gate policy document plus one anonymised override showing both fields properly filled in. Anonymous, permanent exceptions are how accountability evaporates quietly; named, expiring ones are how it survives even a lively sales quarter.
Section 4: Freezes
Ask how the vendor protects your peak seasons — the year-end renewal rush, the summer viewing calendar, quarter-close. The Atlas taxonomy counts four: halting all code work across named calendar dates — a type DORA’s evidence treats coldly, since the deferred queue returns afterward as one undignified lump; narrowing the ban to particular classes of change; blocking releases through designated clock windows; and the budget-triggered halt that spares only top-priority and security work once reliability spending runs dry. Evidence to request: which of the types the vendor operates, written down, together with the triggers that arm them. The numeric type earns extra respect in negotiations, because a budget cannot be argued with the way a date can.
Section 5: The numbers
Ask which release metrics they will share with you quarterly. The Atlas’s core set translates directly into service language: exposure per faulty release, measured in user-minutes touched; the minutes required to restore a trustworthy state; the early-detection ratio; and lead time, merged code through to complete exposure. Evidence to request: three numbers, each with dates, trending across at least two quarters. A vendor already computing these numbers wants you to see them; a vendor who cannot has been steering your client experience on intuition and luck.
Scoring your ReleaseOps audit honestly
Score one point for each of the five sections where evidence — not brochure language — actually answered the question. Four or five points: renew with confidence, then ask whether the quarterly metrics feed can start this contract year. Two or three: renew, while requiring the gaps to close before the next renewal cycle — the Atlas’s ninety-day arc (policy and inventory first, dark deploys and a drilled reversal second, monitored gradual exposure third) is a fair ask to put in a renewal letter. Zero or one: treat the platform as the operational risk it has just declared itself to be, and begin timing an orderly exit. The Atlas’s maturity ladder — ad hoc climbing through repeatable and decoupled toward progressive and adaptive — gives that same renewal conversation a scale both parties can point at. Its ReleaseOps documentation at the Ops Atlas expands every section above into the underlying mechanisms.
Property professionals already audit everything else that matters — title chains, structural surveys, tenant references — and this is that same discipline, pointed squarely at software. Readers planning their own practice’s wider technology decisions will find kindred method in the Pegasus Estates approach to real estate and in the method set out in simplifying complex property decisions; both argue that evidence beats instinct in high-stakes purchases, which is, word for word, this audit’s working thesis. And for the career-side of the same discipline, the practical DevOps learning roadmap shows how team members can grow into running audits like this one themselves.
Send the five sections to your incumbent vendor first, not to their competitor. Read the answers twice: once for what they state, once — the more revealing pass — for what they sidestep. Vendors are, in the end, the way they release — never the way they demo.
