Why ops teams end up running Airtable, Zapier and Monday.com at the same time

Nobody chose this stack. It accumulated.

The sequence is almost always identical. The spreadsheet stopped holding, so you moved the records into Airtable, which was a genuine relief. Then the team needed to see work moving rather than read rows, so a board went into Monday, because Airtable's views never quite felt like a board. Then the two needed to know about each other, and a person copying between them twice a day was obviously absurd, so Zapier went in the middle.

Three good decisions. Each one solved the problem in front of you. And the result is an architecture nobody designed, running your operation, with a maintenance bill that arrives as your time rather than an invoice.

It is worth understanding why this shape keeps happening, because it is not a failure of judgement. It is what happens when each tool solves only part of the problem.

Every ops system needs three things

Strip away the vocabulary and every operational system, in every industry, needs the same three parts.

Somewhere the records live. Suppliers, orders, properties, sessions, claims, whatever your nouns are. This layer has to hold the truth, keep relationships between things, and still be right in eighteen months.

Somewhere people work. A place a human opens to see what needs attention and to move something forward. Records nobody can act on are an archive, not an operation.

Something that acts without a human. The reminder, the escalation, the handover to the next stage. The parts of the process that should not depend on somebody remembering.

The three are not optional and they are not independent. Automation without records cannot know the state of anything. Records without a process are a filing cabinet. A process nobody can see is a diagram in someone's head.

The trouble is that affordable tools tend to solve one of these well, gesture at another, and leave the rest to you.

What each tool actually owns

Being fair here matters more than being clever, so here is the honest version.

Airtable owns the record layer. It is a real place for structured data with relationships between tables, and for a team coming off spreadsheets it is a large step up. Its automations are real too. What the architecture does not give you is enforcement. A status in Airtable is a field somebody edits. Nothing stops a record moving to Approved with the approval field empty, because the status and the condition are two independent pieces of data that happen to sit next to each other.

Monday.com owns the human layer. Boards are the best answer on this list to "what is the team looking at," and people understand them without training, which is not a small thing. What it is not is a shared record store. Boards hold items, so the supplier on your onboarding board is a different object from the supplier on your claims board, sharing only a name. And automation is thin on the entry tiers most teams start on — enough to hit a ceiling faster than you expect.

Zapier and Make own automation, and hold nothing. Both are good at what they do. Neither stores your data, by design — that is the trade that makes them work with everything. It also means neither can answer "what is the state of order 4471 right now," because neither has ever known. They see events passing through, not the thing the events are about.

Read the table across rather than down. There is no row with three answers in it. That is the whole reason your stack has three logos in it.

The seams are where the work goes

Once three tools are in place, the interesting part is not the tools. It is the joins between them.

Nothing holds the whole truth. Each tool has a third of the picture. So the ordinary question — "where is this and why?" — means checking a record in one place, a board in another, and whether the automation between them fired. No system can answer it. Only a person can, and that person is you.

The audit trail has holes exactly where it matters. All three tools log their own changes competently. None of them logs the sequence. When something goes wrong across a seam — the record was updated but the board was not, or the automation fired twice — the evidence is split across three histories, and reconstructing what happened means opening all three and matching timestamps by eye.

You pay three times, on three incompatible models. Airtable and Monday charge per seat. Zapier charges according to usage and plan limits. Make bills around credits rather than users. Adding people, volume and automation affects each bill differently. There is no single number to plan against because you are not really buying one system. You are buying three products that happen to support the same operation.

Every seam has an owner, and the owner is a person. Somebody built the connections, and that somebody now owns them permanently. When a field gets renamed in one tool, something breaks silently in another, and it stays broken until a human notices.

The stack is genuinely cheaper than a developer, which was the entire point, right up until you count the hours of the person holding it together and realise the saving moved rather than materialised.

But don't Notion, Coda or Retool already do this?

It is the obvious question, and it deserves a straight answer.

Notion and Coda put records and the place people work inside one product. Retool goes further and lets you build a genuine interface over your data.

But closeness is not enforcement.

In Notion and Coda, the record layer is still a document or flexible table — structure you are free to set up, rather than structure the system holds you to. A status is still a property somebody edits.

Retool solves the interface, but assumes you already own a database and have the engineer to wire it up — which is the resource the teams in this article specifically do not have.

The distinction that matters is not how many layers a tool can show you in one window. It is whether the layer checking the rule can actually refuse the move.

Putting the three layers side by side gets you a tidier version of the same problem. Making them the same layer is what changes it.

What changes when the three layers are one

None of this is an argument that Airtable, Monday, Zapier or Make are bad software. They are good software solving the problem each set out to solve.

The argument is that three good tools do not add up to one system.

When the records, the process and the automation sit in one place, four things stop being your problem.

Rules can actually be enforced. A stage can require an owner, a filled field, an attached document, a written note. If the condition is not met, the move does not happen, and the person is told why. It is why a status can be a rule rather than a colour — whether a person clicks the button or an automation does.

The audit trail is a single sequence. Who moved what, from what to what, when, and what they had to supply to be allowed. Not three logs to correlate. One order of events.

Adding the second process costs less than the first. The records already exist and already know about each other, so a new process connects to what is there instead of becoming another island with another bridge to maintain.

There are no seams, because there is nothing to join. The integration work is not reduced or automated. It stops existing.

The stack you did not choose

The honest reason ops teams end up here is that every individual step was correct.

Moving off the spreadsheet was correct. Adding a board people could read was correct. Automating the copying between them was correct. There is no decision in that sequence anyone should regret.

What went unnoticed is that three correct decisions produced an architecture, and nobody was ever asked to approve it.

It has no owner, no documentation, and no support contract. The vendors support their own products, which work fine.

The seams between them are yours.

That is worth knowing before the next tool goes in, because the fourth one solves a real problem too. By then the thing running your operation will be four products, five joins, and one person who understands the whole shape and cannot take a holiday.

If that person is you, this is the thing worth doing something about before the fourth tool goes in.

What we're building

OpsOlive is being built around a simple idea: the records, the workflow and the automation should share the same underlying state.

We are currently in early access with a small group of design partners — operations people who have lived the three-tool stack and want a hand in shaping what replaces it.

The record and workflow layers are live, and the automation engine is being built alongside them.

If you recognised your own operation somewhere in this article, that is more or less the only qualification.

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