Describe it, don't build it: what comes after no-code automation

The automation broke on a Tuesday, when somebody renamed a column.

Nobody noticed for three days. It was the one that flagged work sitting too long without an owner, which is the flag that stops things quietly ageing past the point where you can still do something about them. By the time anyone looked, several had. Working out how many meant going back through emails by hand, because the only place the sequence of events existed was in people's inboxes.

That is not a story about a bad tool. The tool did exactly what it was told. It is a story about who was holding the tool together, and what happened the week that person was busy with something else.

Operations teams have been handed three generations of answer to this problem. Which one you are currently living in explains most of what is frustrating about your week.

First, you ask for a developer

The obvious fix for a process running on spreadsheets is software built for the process. So you ask.

The request does not get approved. Not because anyone disagrees with you, but because a developer costs around ninety thousand euros a year fully loaded, and operations is the last team in the building to win that argument. Tech gets tooling. Sales gets a CRM. Marketing gets a stack. Operations gets a spreadsheet and a reputation for coping.

Say you win anyway. Now the tool exists, and every change to it goes through a person who has other priorities. A new client wants an extra sign-off step. That is a ticket. A supplier changes the format they send you. That is a ticket. Six weeks later you are still explaining, in a meeting, what "confirmed" means in your process, to someone who will implement a version of it that is almost right.

The work got automated. The bottleneck did not move.

So you build it yourself

Then the no-code tools arrived, and for a lot of ops teams they were the first genuine relief in years. Airtable to hold the records. Monday or ClickUp for the board. Zapier or Make to connect them. No ticket, no developer, no six-week wait. You could try something on a Tuesday and fix it before lunch.

That deserves more credit than it usually gets in an article like this one. Removing the developer from the middle of every small change was a real shift, and nothing that comes next makes it less true.

But look at what quietly happened. You now run three subscriptions instead of one, and pay per seat on two of the three. As of August 2026, a five-person team on Airtable, Monday.com and Zapier together, billed annually, on the cheapest tiers where automation is actually included, pays a little over two hundred euros a month. That is the floor. It is before anyone needs the tiers that enforce real permissions, before anyone hits a record ceiling, and before the automation volume goes past the smallest bundle any of them sell.

And the most expensive line does not appear on any of those invoices. It is you. The wiring between the three tools is now a thing somebody owns, and that somebody is the person who built it. You did not buy a tool. You became one.

Where it actually breaks

Four things go wrong, and they go wrong in the same order in every company.

A status is a colour, not a rule. Anyone can drag a card to Done. Nothing checks whether the reference number was filled in, whether an owner was assigned, whether the sign-off actually happened. The board shows the state you wish you were in. Finding out whether that is true means asking someone. Which is how something reaches a customer while the check that was supposed to gate it sits unopened in a spreadsheet, and how the first person to discover the gap is the customer.

Your data does not know itself. The supplier in the onboarding base is not the same supplier as the one in the tracking sheet. They share a name and nothing else. So every question that crosses two processes becomes a manual cross-reference. One head of operations we interviewed spent four hours a week going through three separate sources to answer a question a client asked in one sentence. Every new process becomes another island, and the bridges between the islands are the automations you now maintain.

When the process changes, everything already moving is at risk. You edit the flow on Thursday because a client asked for an extra approval. The forty items already in progress were started under the old rules. What happens to them is usually nobody's decision. It is whatever the tool happens to do, and you find out from the exception rather than from the tool.

Only one person can read it. Not the diagram, the reasoning. Why there is a filter on step four. What the branch labelled "check" is checking. The person who built it knows, and everyone else works around it. That is fine right up until that person takes two weeks off.

The third and newest answer: describe it

Describe-it-don't-build-it means you write down what your operation actually does, in your own words, and the system builds the structure from that description: the records you work with, the stages they move through, the rules for moving between them, and the things that should happen automatically. When the process changes, you change the description rather than rewiring anything.

Five things are different, and none of them are about saving clicks.

It speaks your vocabulary, not a template's. You might say Suppliers, Loads and Claims. Someone else says Trainers, Sessions and Rooms. A third says Properties, Turnovers and Sign-offs. Underneath, that is the same machinery holding different words, which is the point: nobody should have to rename their own operation to fit a structure somebody else designed for a company that is not theirs.

Rules get enforced, on people and on automations alike. A stage transition can require an owner, a filled field, an attached record, a written note. If the condition is not met, the move does not happen, and the person gets told why. This is the difference between a status that describes reality and a status that guarantees it, and it holds whether a human clicks the button or an automation does.

Changing the process does not disturb work already in flight. Publish a new version of a workflow and the orders already moving keep running under the rules they started with. New work picks up the new rules. That sounds like a small technical detail and it is the difference between improving a process on a Thursday afternoon and only ever touching it during a quiet week that never comes.

It remembers, so the second process costs less than the first. Add a process three months after the first one, and the system already knows what the records are, which of them exist, and how they relate. No re-import, no fresh island, no new connection to maintain. Your current stack gets heavier with every process you add to it. This gets lighter, because the expensive part was built the first time.

The audit trail writes itself. Every stage change is recorded: who moved it, from what to what, when, and any note they had to leave. Not because someone remembered to log it, but because there is no other way through.

OpsOlive is in closed beta now, with a small group of design partners. The data layer and the workflow engine are live and running; the automation engine is the piece being finished. Treat the description above as what we are building and partly running, not a finished product with a decade of polish on it.

What this does not fix

An article like this is worth very little without this part.

You still have to know your own process. The most common surprise is not technical. Three people describe the same workflow three different ways, and the disagreement was invisible until somebody tried to write it down. Describing your operation surfaces that in the first week, which feels like the tool creating a problem. It did not create it. You were paying for it quietly, in exceptions and rework, the whole time.

Vague in, vague out. "Notify the team" does not say who, through which channel, or what happens when nobody responds. Getting a description precise is real work. It is the same thinking you were always doing, done in your own language instead of inside somebody's automation builder, which is better, but it is not free.

A person still has to say yes. The system proposes the structure; a human reviews it and publishes it before anything real is stored against it. That is deliberate, and it means this is not a machine that quietly reorganises your operation overnight. It also means it is not magic, and the review takes time.

When the system cannot do something, it says so. Ask for something outside what the product supports and it records the gap rather than inventing a half-answer. Useful, honest, and still a no.

The outside world remains the outside world. Partners' systems go down. Suppliers send the wrong format. Somebody's inbox rejects an email at two in the morning. No description of a process changes what happens when the thing on the other end of it breaks, and any tool implying otherwise is selling something.

The holiday test

There is a simple way to work out which generation you are currently in, and it does not require evaluating anything.

Picture two weeks away. Phone properly off. While you are gone, something changes, because something always does: a new client needs an extra approval step, a supplier switches the format they send, a deadline rule moves from seven days to five.

Somebody has to make that change. Ask yourself who, in your operation as it stands today. If the answer is a developer, you are in the first generation and you are waiting. If the answer is that it sits there until you are back, because you are the only one who understands the wiring, you are in the second, and the tool you built to save your time has quietly become the reason you cannot leave.

The third generation is not really about artificial intelligence, or building software without code, or any of the other things it gets marketed as. It is about whether the person who understands the process is also the person who can change it, on the day it changes, without becoming the single point of failure in their own operation.

Vilde A. Hansen is co-founder and CEO of OpsOlive. LinkedIn