Last week, I shipped a feature to my commitment intelligence platform, Mindmoor at midnight. A feature that no engineer would have ever thought to build.
It’s called “Waiting On”. When you finish a task in Mindmoor, a modal asks what happens next. If the next move isn’t yours. If someone else owes you something. The system holds that thread. It tracks how long it’s been open and escalates nudges on a schedule, instead of letting the commitment quietly evaporate.
Nobody writes that ticket. It doesn’t appear in a requirements doc because it isn’t a feature request. It’s a scar. It comes from twenty-five years of watching revenue slip through the gap between what someone agreed to do and what anyone remembered to check on.
I couldn’t have written a line of that code three years ago. I still wouldn’t call myself an engineer. But I knew exactly what to build, and that turned out to be the harder half.
Every Friday, I publish The AI Operator's Brief. It’s a one-page dispatch on what actually happens when AI meets real-world business applications.
You get the signal on what moved, what we’re seeing in the field, and one tactical thing you can build by Monday. No code required.
The Constraint Moved (and Almost Nobody Adjusted)
For most of my career, the math only ran in one direction. Engineering capacity was scarce and expensive. Domain knowledge was abundant and free, sitting in the heads of the people running the process every day, available for the cost of a meeting.
So, we organized around the scarce thing. Requirements were gathered from the operators, translated into specs, prioritized against a roadmap, built by a team that had never run the workflow, and delivered two quarters later to a group of people who spent their first week explaining what got lost in translation.
That whole apparatus existed for one reason: building was expensive.
Building isn’t expensive anymore. The moment that changed, the scarce input flipped. The bottleneck is no longer the ability to build the thing; it’s the knowledge of what the thing actually needs to do.
Most organizations simply don’t get it, yet. They still route AI capability to the group that historically held the build capacity, which is exactly backwards. They’ve taken the input that is now abundant and handed it to the people who were already good at it, while the true constraint sits three floors away in operations, unbudgeted and unasked.
What Actually Gets Lost
Call it exception knowledge. It’s the accumulated understanding of why a workflow deviates.
It’s knowing why that one account gets invoiced on a different cycle. Why the deal stage after discovery gets skipped for renewals, but not for expansions. Why the weekly report nobody reads still gets produced, and exactly what breaks in October if it stops. Why the intake form has a field that looks redundant, but absolutely isn’t.
These aren’t edge cases. In any business older than four years, the exceptions are the business. They are the compressed record of every customer who threatened to leave, every deal that fell apart at legal, and every process that broke once and got patched.
Strip them out, and you haven’t simplified the workflow. You’ve described a company that doesn’t exist.
Exception knowledge has one durable property: it does not survive translation. It isn’t written down anywhere because the person holding it doesn’t experience it as knowledge; they experience it as just how things work. Ask them to document the process and they’ll give you the clean version, because the exceptions live below the level they think to mention. You only surface them by watching, or by being the person in the seat.
This is why the operator holding all of that knowledge has almost never been in the room where the tool was selected.
What I Learned by Finally Building it Myself
I’ve spent my entire career in technology without writing a line of code. Twenty-five years. From carrying a bag in media sales through executive RevOps leadership at large media and tech companies. I sat in the requirements meetings. I signed the contracts. I ran the teams that lived with the results.
About two years ago, I started building. I’m self-taught, I got there through AI tooling, and I have no interest in dressing that up as anything other than what it is.
What came out of it wasn’t a toy. It’s a Commitment Intelligence platform running on Supabase and React with the Anthropic API underneath, and it has completely replaced HubSpot. It’s a client and project management system that replaced Trello. It’s a newsletter engine that replaced MailChimp. I pay nothing for three pieces of software that do exactly what my business requires, with zero fields I don’t use and no workflows I have to bend myself around.
Here is the part that matters for this argument, and it isn’t that I learned to code.
The products are good because I already knew the workflow cold. Every design decision that makes them useful traces back to something I lived through. The next-action prompt exists because I’ve watched hundreds of tasks get marked complete with no next step attached, and then die. Waiting On exists because delegated commitments are where pipeline goes to rot. I didn’t discover those problems while building. I brought them with me.
If I had hired a traditional developer, I would have gotten a competent platform. I would have spent six weeks writing requirements, another six in review cycles, and I’d have ended up with something that handled the clean path beautifully while forcing me to manage the exceptions by hand. Not because the developer was bad at their job, but because I wouldn’t have known how to tell them what I know. I didn’t know it in words. I knew it in the flinch when a task closed with nothing behind it.
The translation tax isn’t just a delay. It’s a filter, and exception knowledge is precisely what it filters out.
Where This Argument Stops
I want to be careful here, because there is a version of this that gets a lot of applause and ultimately gets somebody fired.
Building the thing and shipping it to an enterprise are two different disciplines, and I found that boundary by walking straight into it.
Security is real. Default auth on a database is not an enterprise security posture, and I learned that not from a blog post, but from hardening my own product once real client data was on the line. Row-level access, tenant isolation, key management, audit trails, SSO for organizations that require it, the operational assurance of knowing what is exposed as you add platforms. None of that is optional, and none of it is intuitive to an operator. It is a profession.
So is data integrity at scale. So is uptime you can put in a contract. So is what happens when the person who built the thing goes on vacation.
The honest version of this claim is narrower than the exciting version: An operator with AI can now build the working system. Making that system safe, supportable, and enterprise-grade still requires the discipline that Engineering and IT have been carrying all along.
What This Changes on Monday
Hiring: Stop screening for tool certification. Certification is a proxy for the input that just became abundant. Screen instead for two things that are hard to fake: depth of exception knowledge in a specific workflow, and a willingness to build rather than request. The first took a decade to accumulate and can’t be taught in a quarter. The second is their disposition. You can find it by asking a candidate what they’ve automated for themselves that nobody asked them to do.
Org Design: The technical org doesn’t lose here; it changes shape. The role moves from sole builder to platform and guardrails: the environments, the security floor, the standards, and the review that keeps an operator’s build from becoming a liability. The build itself moves to where the workflow lives. If your model requires the workflow owner to explain their job to someone else before anything gets built, you’re still paying the translation tax.
Budget: This is the one that decides whether any of the above actually happens. Follow the money in most AI programs, and it sits with the group furthest from the frontline workflow. That means you’ve funded translation rather than output. My own comparison isn’t a controlled study, but it’s the honest number I have: two quarters and a vendor contract to get a system built the old way, versus a few weeks of nights and weekends to get one that fits exactly. That gap isn’t mostly engineering speed. It’s everything that never had to be explained.
That gap is the whole game. It’s the same gap that shows up when a company approves AI spend, stands up a committee, runs a pilot, and eighteen months later can’t point to a single workflow that actually changed. Money moved. Nothing activated.
The people who could have activated it were never funded, never asked, and in most cases, never even told the budget existed.
The Person You Are Looking For
Go back to the modal. Midnight, a feature nobody requested, built because I had spent twenty-five years watching commitments disappear into the space between two people.
Somewhere in your company, there is a person like that for your workflow. They know why the exception exists. They’ve known for years. They have probably built something ugly and effective in a spreadsheet to work around it, and nobody in the AI conversation has ever asked them a single question.
Name three of them this week. Not the loudest, not the most technical. The three who know exactly why things are the way they are. Ask them what they would build if the building were free.
The building is free now. That is the entire shift, and most of the org chart hasn’t caught up.
Every Friday, I publish The AI Operator’s Brief. It’s a one-page dispatch on what actually happens when AI meets real revenue operations. You get the signal on what moved, what we’re seeing in the field, and one tactical thing you can build by Monday. No code required.