Write two of the conditions yourself.

Open your tracker. Find something marked done in the last fortnight, ideally something you remember being pleased about. Underneath the title there will be a short list, three or four lines, of what had to be true before anybody was allowed to call it finished.

Read them. Then count how many mention a person who pays you, or a number your business tracks.

I am not going to tell you the answer, because the finding only lands if you go and get it. It takes about thirty seconds and it is the most informative thirty seconds you will spend on your build this month.

That short list is the standard.

It has a name, and the name undersells it. Acceptance criteria sound like paperwork, something a delivery manager tidies up on a Friday. They are the only binding part of the document.

Not the ticket title, which is a label. Not the description, which is context. Not the estimate, which is a guess that everybody has agreed to stop arguing about. The conditions underneath are the standard, because on a software build done means precisely one thing: the conditions are satisfied. Nothing more, and nothing less. Everything else on the ticket is commentary. N°33 made that case properly and I will not relitigate it here. The short version is that the conditions are where the meaning is stored, and whoever writes them is deciding what finished means on your build.

Who writes them, and why that is correct.

On almost every engagement, the people building the work write the conditions the work is judged against. My teams did. I built and exited an agency at Atomise and I would defend the practice in any room, including this one.

The reason is not convenience, it is competence. Early in a build the only people who understand the system precisely enough to say what finished looks like are the people inside it. They know which state the record has to be in, which call has to have returned, which edge case was agreed and which is deliberately out of scope. A founder writing those lines in month two would write them wrong, and the work would then be measured against something incoherent, which is worse than the problem this issue is about.

So good suppliers write good conditions. That is the premise of everything below rather than a politeness I am extending before turning on them. If the conditions on your build were badly written this issue would be easy and the fix would be a conversation. They are not badly written. That is the whole difficulty.

Which makes the standard internal by construction.

Because the conditions are written from inside the system, they describe the system.

Here are three off a real ticket, of a kind I have written and signed off hundreds of times.

Diagram · what “done” means on one ticket

Illustrative, and the first three are the point. They are correct, checkable and worth having, and not one of them mentions anybody who pays you. The last two take about a minute to write and are the only lines on the ticket your business appears in.

Every one of the first three is right. Every one is checkable by somebody who can read the code. Every one is worth having, and I would be unhappy to find a ticket without them.

And not one of them mentions a customer, a renewal, a price, a competitor, or a number anybody outside the building has ever asked about. They could not. The person writing them has not met your customer, is not in your renewal conversations, has not read your board pack, and finding any of that out is in nobody's scope on either side of the contract.

So the standard is internal by construction, not by neglect. There is no villain anywhere in that paragraph, which is exactly why nothing about it changes on its own.

Two lines, written by you.

The fix is small and it is yours rather than theirs. On the handful of items that genuinely matter, you write two of the conditions.

One says what has to be true for a real customer. One names which number in the business this is meant to move, with today's value written next to it.

That is the whole intervention. Two lines, in plain English, checkable by somebody who has never opened the code, and agreed before the work starts rather than bolted on at review, because a condition added at review is a complaint. A condition is simply a belief made checkable, which is the same move one level down from the plan to the ticket: it is what turns we think this will help into something that can turn out to be wrong.

On Tuesday I published ten of them on LinkedIn, written out in full so that a founder can steal them rather than compose them from scratch. I am not going to reprint them here. Take the two that fit the item in front of you and change the nouns.

Which tickets, because this does not scale.

It does not, and it should not. Five or six a quarter. Not fifty, and not every item in the sprint.

A condition written from outside the build costs something to satisfy, and what it costs is paid in the same currency as everything else on an engagement: the time between deciding something and getting it in front of a person. Every build has a speed limit and most teams have never measured theirs. Loading fifty client written conditions onto a backlog is an expensive way to discover what yours is.

So the test for picking them is not size and not enthusiasm. It is this: the items where a wrong answer costs you a month or a customer. Everything else can be judged perfectly well by the standard the builders already write.

That list is almost never the top of the build's order, and the reason is worth understanding rather than resenting. A backlog is normally sequenced by delivery logic, for sound engineering reasons: foundations first, work that unblocks other work, items a team can start without waiting on you. Nobody sequencing it that way can weight an item by which customer conversation is at risk or which number the next investor will open with, because nobody has told them and finding out is in nobody's scope. Your five or six sit at the top of your order, not theirs, and the two lists are allowed to differ.

One more that is easy to miss. Include the item where the right answer might be a smaller version than the one that was quoted for. That question rarely arrives from the supply side, not because anybody there is unable to ask it but because proposing less work is an argument against your own engagement, and the chair that finds that question comfortable is the one on your side of the table.

It slows the ticket down. That is the return.

Two objections left and the first one is honest, so let me concede it properly.

This does slow the ticket down. A condition written from outside the build has to be read, understood, argued about, sometimes refused, occasionally admitted to be impossible this quarter. Sometimes it stops the ticket entirely.

That is the return, not the cost. A ticket that stops because somebody asked what has to be true for a real customer, and nobody in the room could answer, is the cheapest available version of finding that out. The expensive version ships, gets demoed, gets signed off with genuine satisfaction on both sides, and reappears four months later as a feature nobody uses next to a number that did not move. N°63 made the same argument one level up: a gate that has never been capable of producing a no is not a gate. The same is true a level down.

The second objection comes from the supplier, and it is worth knowing in advance what a good answer sounds like. A good build partner reads two client written conditions and asks how they will be verified, who decides, and what happens if the number does not move. That is engagement, and it is the response you want. A partner who tells you that conditions are an engineering concern and best left to the team has told you something real about how the next nine months will go, and they have told you cheaply.

Who holds the pen.

It cannot be the supplier alone. Not because they would write them badly, but because you would be asking them to author the standard their own work is measured against, from a chair that has never met your customer. That is not a character problem and no amount of goodwill fixes it. It is also why quality ownership is a senior function on the client side rather than a testing activity somewhere downstream, which is the argument in N°29.

And it cannot be you alone. Not for want of ability, but because you have one build's worth of pattern, and the conditions that matter most are the ones you have not yet learned to worry about.

Which is the same third chair N°63 ended on, and it is not a coincidence that two consecutive issues arrive there from opposite directions. A phase gate is where somebody asks what evidence the last eight weeks produced. A client written condition is the smallest possible unit of that evidence, one ticket at a time. Same chair, different scale.

It is also, and I think this is the strongest thing that can be said for it, the only moment inside a live engagement where the stop question gets asked in writing, by somebody whose own money is on the answer. Nothing else in the arrangement has that property. And since I sit in that chair for a living, the honest disclosure is that advice which cannot make the job smaller is not really advice, so the chair is only worth filling with somebody it costs something.

So take the one item that matters most this month, the one where a wrong answer costs you a month or a customer. Write the two lines. Then send them to your build partner before the work starts, and read what comes back.

The reply is the diagnostic. You will get one of three. A question about how the condition will be verified and who decides, which is the good one. A reasonable negotiation about scope or timing, which is fine and is what a working relationship looks like. Or an explanation of why conditions like that cannot be written, which is the most useful email you will receive this quarter, and the one worth forwarding to whoever helps you think about the build.

N°65 asks the question one level further upstream, before any of this. A condition you write is written on somebody’s behalf, and on most builds nobody can say whose.