The Outward Turn
The people who use the software are the ones building it
On 21 August a member of the accounts-payable team at a Bahamian company sent a WhatsApp at 5:03 in the evening: she needed the cash breakdown from an end-of-day closeout she could not see. No person read her message. It was checked against the company's written business rules, filed, and an agent fixed it: three commits and a reply telling her it was sorted. Twice she said it was not. Fifteen minutes before the fix that stuck, her voice note had named the bug. Her "this is what I needed to see" closed the ticket. I own the company, and I found out from a summary.
That request was one of 244 since 6 July. This essay is about the approach behind it: the people who use the software are the ones building it. Not a suggestion box, not a feature-request queue read by a vendor once a quarter. The change itself, asked for in their own words, built, tested, deployed, and judged done by the person who asked.
What the turn is
Why doesn't business software change? Because a vendor sells it. Your week is not on their roadmap, and no ticket you file will put it there. It will not change. It will never change. So the people who live in it all day, the clerk closing out a register, the dispatcher juggling routes, bend their day around what it cannot do. That is the script every business runs: the software runs the business.
AI agents made building cheap. That is not the turn. The turn flips the script: the business runs the software, not the software runs the business. The authority to change it moves outward, to the staff who use it, safely enough that an owner can sleep. Three things make that safe:
- Written business rules. A plain file says what the software is for, what it must never touch, and who may ask for changes. Every request is judged against it.
- A floor that cannot be lowered. Some actions always stop and ask a person: messaging a customer, deploying anything the rules flag, moving money, reading customer data. No judgment call, by the model or anyone else, can waive that.
- The requester is the judge. Nothing counts as done because the system says so. It counts as done when the person who asked says it is.
How it runs at a real company
The numbers below are from the company I run day to day on this software, a 133-person operation, read straight from the production databases.
1. A named person asks. The rules name eight staff who may request changes and what each is trusted with. The other 126 employees use the app; they do not change it. Anyone else gets a polite decline.
2. The request is read and sorted. Text or voice note, in their own words. 415 messages have become 244 requests; 147 were noise. At most one clarifying question goes back.
3. It is judged against the written rules. Does it fit what the software is for? Would it need anything on the floor? Since 10 July: 200 requests judged, 158 ran on their own, 38 stopped to ask first, 4 were refused.
4. Outside the lines, the owner gets one card. A message on my phone with three buttons. 83 cards so far: 68 approved, median 16 minutes from card to tap. That is the entire management overhead of the out-of-bounds cases.
5. An agent builds it and has to prove it. It reproduces the problem, fixes it, runs the tests, verifies against real behaviour, and only then deploys. A fix that cannot be verified is parked, not shipped. Authentication, anything that could drop data, and the accounting books are parked for a human by rule. 226 requests filed, 160 resolved, 104 of them citing a change that is live in production today.
6. The person who asked says when it is done. The notice goes out once the change is live. "Sorted" closes it. "Still not right" sends it straight back to stage five with nobody in between. Median from request to resolved: 29 minutes. 109 of 159 closed inside an hour.
Where it still needs a person
Honesty is the price of the claim, so: one member of staff sent 197 of the 244 requests; the approach is proven deep before it is proven wide. 62 requests sit in a "reviewing" state that mixes "needs a human" with "shipped, remainder is a product call". Twelve cards were never tapped. Eight requests were told "sorted" twice; the worst was a reply-binding rule that matched an "Ok" to a 16-day-old fix, replaced the same day. And for six weeks the written rules said pushes needed my approval while the system shipped 141 fixes on its own; the document caught up on 21 August.
None of that is hidden, and that is the point. The part of the loop that still needs a person is measured, and the measurement says where the next month goes.
What this means for your company
If your staff keep a list of things the software gets wrong, and that list routes through a vendor who ships quarterly, then the software is running the business. Flip it. Your team sends a WhatsApp and the software fits the business by the end of the coffee.
Two doors:
If you run a business on software you cannot change fast enough: IslandFlow launches to external customers in a webinar on 15 September. What you are buying is not a list of modules. It is that your own staff can send a WhatsApp and have the software change, inside written rules you set. Reply and I will send the link.
If you build with agents and want to know whether their "done" is real: I am taking five verification pilots. Send an AI-built codebase or an agent fleet. I run the harness behind stage five: every implicit claim extracted and checked, every "done" tested against evidence, findings ranked by what breaks, proof attached. Two weeks. $2,500. If I find nothing worth the fee, you don't pay. The scanner is free at seatrial.io/scan.
→ ty@seatrial.io. One line is enough.
Method and honesty notes
Every number comes from two production databases read on 31 August 2026 inside a read-only transaction, every row counted, none sampled, with the query kept beside each number. Requesters appear as roles, never names. Change references in the resolution notes were checked against the repository's main branch, which deploys automatically; 104 of 160 resolved requests cite one that resolves. The video above dramatizes the loop with a typical mid-morning timeline; the times in this essay are the real ones.