Airtable vs Supabase for agencies: a three-axis scorecard

It is Friday afternoon. An agency founder in Utrecht closes their laptop, glances at the Airtable invoice that just arrived (twenty-three seats, half of them dormant), and notices the Zapier task counter sitting at 14,000 of 20,000 for the month. They have a flight to Lisbon on Sunday. If the Monday client-reporting automation breaks while they are gone, four people in the office have no idea where to look.

This is the moment most agencies finally ask the question they have been avoiding: do we keep this stack, or do we rebuild it on something we actually own?

We get asked some version of this once or twice a month, almost always by Dutch agencies between €1M and €15M in revenue. Below is the method we use to answer it. It is not a verdict on Airtable. It is a scorecard.

The stack agencies inherit by accident

Almost no one chose this stack on purpose. It accreted. Year one, somebody set up an Airtable base to track client tasks. Year two, a freelancer wired three Zaps to push status updates into Slack. Year three, the operations lead added a Make scenario that turns Harvest entries into a weekly PDF. Year four, the founder bought Airtable Business so they could run automations and gave seats to clients so they could see read-only views.

The monthly bill is now somewhere between €800 and €2,800. There are 40+ live automations across two or three vendors. Nobody has a complete inventory. The person who built the original Zaps left in 2023.

Rebuilding sounds appealing. So does leaving it alone. The right answer is almost never the one that feels emotionally cleaner. We score it.

The three axes that actually matter

Most rebuild-versus-keep conversations get lost in feature comparisons. Whether Supabase has a kanban view. Whether Airtable Interface Designer can do drill-downs. Those questions do not decide the outcome. Three things do:

1. Per-seat cost at year three, fully loaded.
2. Who can fix it on a Tuesday when the founder is unreachable.
3. What an acquirer or investor will ask to see in due diligence.

Score each axis from one to five. Rebuild becomes the right answer when the total clears thirteen. Below that, the existing stack usually wins on the maths.

Axis 1: per-seat cost at year three

Airtable Business is roughly €50 per seat per month. Zapier Professional starts around €70 per month and scales aggressively with task volume. Make is cheaper per task but the same shape. The honest year-three number for an agency at twenty seats with a real automation load is around €40,000 (€50 × 20 seats × 36 months, plus €5,000 for Zapier or Make at typical agency volumes).

A Supabase rebuild lives in a different cost class. Supabase Pro is $25 per month for the project, with compute add-ons for production workloads. A small Deno or Node scheduled-function deployment costs another €20 to €50 per month. Three years of hosting comes in under €3,000.

The headline gap is roughly €35,000 over three years. The rebuild itself eats some of that. A reasonable migration for an agency-sized automation footprint runs €15,000 to €30,000 depending on how many integrations are involved.

Score the axis 1 if the rebuild pays back in year five or later, 3 if it pays back in year three, 5 if it pays back inside eighteen months.

Axis 2: who fixes it on a Tuesday in August

This is the axis founders underweight, every time. The honest version of the question: when something breaks and you are on a beach, who finds the broken thing and who fixes it?

For an Airtable plus Zapier stack, the answer is usually "anyone who can read English and click around." That is genuinely a strength. A junior account manager can open the failed Zap, see the broken step, and click Replay. For 80% of failures, that is fine.

The problem is the other 20%. When a Zap silently changes its behaviour because Airtable renamed a field, or when a Make scenario runs twice because of a webhook retry, the failure is invisible. Nobody sees the broken state because there is no logging anyone reads. The client reporting goes out wrong for three weeks before someone notices.

A Supabase plus scheduled-functions stack inverts this. Almost nobody on the agency team can debug it directly. But two things are true: it has real logs (queryable, with timestamps), and any competent developer you hire on a freelance platform can read the code in an afternoon. The bus factor is one full-time person at the agency, but the recovery cost from "that person left" is bounded.

Score the axis 5 if the current stack is held together by exactly one person who would be hard to replace, 3 if two people share knowledge, 1 if four or more people can fix any failure.

Axis 3: what an acquirer demands to see

The third axis is the one founders never ask about until a year before they want to sell. By then it is too late.

An acquirer, or even a strategic investor, will ask three questions about your operational backbone: where is the code, who owns the IP, and what are you locked into. An Airtable base plus 47 Zaps answers those three questions badly. There is no code. The IP is "this is how Marieke set it up in 2022." The lock-in is total, because nobody documented how the automations chain together.

This is not a hypothetical concern. We have sat in two due-diligence calls in the last year where the buyer's technical advisor asked for a list of scheduled automations and the seller could not produce one. Both deals closed, but at terms that priced in the operational risk.

A Supabase backbone gives you a git repository, migration history, typed function signatures, and a CI pipeline. None of those are exciting. All of them survive a five-minute scan by a buyer's CTO.

Score the axis 1 if there is no near-term exit, 3 if exit is possible inside five years, 5 if there is an active conversation already.

The scorecard in practice

Here is a real example. Names changed. A Rotterdam content agency, eleven full-time, three contractors, around €2.1M revenue. They were paying €1,180 a month across Airtable, Zapier, and a Pipedrive add-on that pushed deals into Airtable.

// Their actual scorecard
const score = {
  costAtYearThree: 4,   // Rebuild quote €18k, SaaS year-3 bill €42k
  busFactor:       4,   // One ops lead held all the Zap knowledge
  acquirerLens:    3,   // Founder open to a 2028 exit conversation
}
const total = Object.values(score).reduce((a, b) => a + b, 0) // 11

// Below our threshold of 13. Recommendation: do not rebuild yet.
// But: write the inventory now, and revisit in 12 months.

We did not rebuild for them. We did a two-week engagement to document every automation, kill seven dead Zaps, and move the single most fragile workflow (the weekly client report) into a Supabase scheduled function that fed back into Airtable. Total cost €6,800. Their year-three bill dropped to roughly €32,000 and the bus factor improved by one notch because the fragile thing now had logs anyone could read.

Twelve months later the score was different. Headcount had grown to sixteen. The rebuild quote got cheaper relative to the SaaS bill. They had started serious conversations with two potential acquirers. We rebuilt the rest.

When keeping Airtable wins

The scorecard tilts toward "keep" more often than agency owners expect. Three cases where we tell clients not to rebuild.

The stack is under €600 a month and stable. The team is under ten and unlikely to grow past fifteen. No exit conversation is happening or expected. In those cases the rebuild quote almost never pays back inside the useful life of the business as it stands.

What we do instead is small, focused work. A documented inventory of every paid tool and every live automation. A kill list of dead Zaps and orphaned bases. One scheduled function that takes over the single brittle workflow that wakes the founder up at night. The total bill for that work is usually under €8,000 and it buys back most of the operational risk.

The trap to avoid is the in-between move: ripping out Airtable but leaving the workflows in Zapier, or moving the database to Postgres but keeping the automation layer in no-code. You end up with the costs of both stacks and the resilience of neither. Pick one side of the fence per axis, and document the decision.

The shape of the migration when it does happen

When the scorecard says rebuild, the migration has a predictable shape. We do not move everything at once. We move the workflow with the worst pain-to-effort ratio first, prove the pattern, then peel off the rest in two-week increments.

The minimum viable backbone is small. One database, a handful of tables, one or two scheduled functions, a deploy pipeline. The first function we usually ship is the weekly client report, because that is the workflow with the highest visibility and the lowest tolerance for silent failure.

// supabase/functions/weekly-client-report/index.ts
import { createClient } from 'jsr:@supabase/supabase-js@2'

Deno.serve(async () => {
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!,
  )

  const { data: clients } = await supabase
    .from('clients')
    .select('id, name, email, report_template')
    .eq('active', true)

  for (const client of clients ?? []) {
    const hours = await fetchHarvestHours(client.id)
    const html  = renderReport(client.report_template, hours)
    await sendEmail(client.email, `Weekly report for ${client.name}`, html)
  }

  return new Response('ok')
})

Schedule it with a Supabase cron job, point it at a real database, and you now have the thing that used to live across three SaaS tools in one file you can read in ten minutes. The whole rebuild is a sequence of files that look like this one.

The five-minute version of this method

The full scorecard is useful when you are about to spend €20,000. For a faster read, ask three questions over coffee with your operations lead.

What does this stack cost us per year, right now, all-in? If the answer is more than €15,000 and growing, axis one is loud. If a senior person on the team got hit by a bus tomorrow, what breaks? If the answer is "weekly client reporting and the pipeline forecast," axis two is loud. If a buyer asked for our automation inventory tomorrow, what would we send them? If the answer is "I would have to spend a week reconstructing it," axis three is loud.

When we rebuilt the reporting backbone for a Dutch creative agency in Q1, the surprise was not the cost saving. It was that the ops lead got her Tuesdays back, because the new system surfaced its own failures instead of waiting to be discovered. That is the kind of process automation outcome we keep optimising for: not flashy, but the founder can take a real holiday.

The smallest thing you can do today: open a spreadsheet, list every paid automation tool you use, multiply by twelve, and write down the name of the person who would fix each one if it broke this afternoon. If you cannot fill in a name, you have your starting point.