Softr Apps Hitting a Ceiling: What Comes Next

Softr is one of the fastest ways to turn an Airtable base into something that looks like a product. A founder with an ops spreadsheet can ship a client portal in a weekend, wire up a login, gate a few pages, and call it a real app. For a lot of early-stage companies that really is enough. Then the ceiling shows up. A paying customer asks why their team admin cannot see the same records as the owner. A partner asks why the approval action does not run a refund. A field technician complains that the app will not work on a patchy site connection. Each of those asks is a symptom of the same underlying fact about Softr, and understanding that fact is the difference between bolting on more Make scenarios forever and accepting that the tool has done its job.

This article walks through what Softr actually is under the hood, the four ceilings we see founders hit, the migration path we recommend, and when you should just stay on Softr and ignore the noise.

What Softr Actually Is

Softr is a view layer on Airtable. That is the sentence to write on a sticky note and keep next to the monitor when you are planning anything more ambitious than a directory. Softr pages are templates that render Airtable records. When a signed-in user loads a page, Softr asks Airtable for the relevant rows, filters them against the visibility rules you configured, and paints the result. When that user submits a form, Softr writes the row back into Airtable. If you change a field in Airtable, the Softr page reflects the new value on the next load. There is no second database. There is no server of your own. There is no place for code to live between the button and the row.

This model is the source of Softr's speed. It is also the source of every ceiling we are about to cover. Softr does not limit you because the vendor is stingy. It limits you because a view layer on a spreadsheet can only do so much before you need a real backend. SmartSuite, Google Sheets, and HubSpot work the same way as alternate sources. The constraint is architectural.

Because Airtable is the system of record, any change made in Airtable reflects live in the Softr app. This is wonderful for internal users who live in grid view. It is dangerous for customer data, because a single ops person with edit rights on the base has more power than any policy you write inside Softr. That matters in a moment when we talk about permissions.

The Multi-User Permissions Ceiling

Softr's permission model has two levers. The first is user groups. You define groups like customer, partner, admin, and assign users to them either manually or by an Airtable field. The second is conditions on blocks. A list block can show only rows where the record's assigned-to field equals the logged-in user. A detail block can be hidden unless the user's group is admin. A form block can allow edits only when the record is in a draft state.

This gets you surprisingly far. A founder can ship a client portal where each client sees only their own projects, and an internal view where staff see everything. That is the ninety percent case. The ceiling is everything above it.

There is no field-level security. If a row is visible, every field you chose to display is visible. You cannot say that a customer sees the amount column but not the internal-notes column on the same row without building a second page. You end up duplicating pages per role, and every schema change has to be repeated across each clone.

There is no real concept of organizations. If your product is multi-tenant, meaning a customer account has several users who all share the same data scope, you have to fake it with an org-id field and match it to a field on the user record. The moment a user belongs to two orgs at once, the model breaks. Softr assumes one user equals one scope.

There is no enforcement below Softr. Remember the first section. Airtable is the database. Anyone who has a seat on the base or a personal access token can read and write every row, regardless of what Softr shows. If you are selling to a regulated industry or a customer who will ask about data isolation, Softr's permission story ends at the UI. There is no row-level security inside the data itself.

When a founder starts asking about SOC 2, per-customer data residency, role matrices with more than four roles, or admin audit logs, the permission ceiling is in the air and the answer is a real backend.

The Custom Logic Ceiling

Softr cannot run your business logic. There are no server functions, no scheduled jobs, no code you can drop into the page to transform data on save. The only escape hatch is the webhook. When a user clicks an action button or submits a form, Softr can fire a webhook to Make, Zapier, n8n, or your own endpoint, and the scenario on the other side does the real work.

For a handful of automations this is fine. The webhook fires, Make waits a second, an email goes out, a Stripe charge runs, a slack ping hits the team channel. The founder feels clever. Then three things happen in sequence.

The first is latency. A user clicks "Approve" and expects the page to update. The webhook fires, Make queues the scenario, runs three steps, and writes back to Airtable. Softr does not know to refresh. The user sees the old state, refreshes manually, and by then the page still lags because Airtable cache has not caught up. Every flow with a synchronous user expectation feels broken.

The second is cost. Make and Zapier charge per operation. A single button click can be five operations. Ten thousand clicks a month, across fifteen flows, becomes a real line item, and the operations usage compounds every time you add a feature. We see Softr apps where the automation bill has overtaken the Softr and Airtable bills combined.

The third is fragility. The logic of the product is now spread across Softr conditions, Airtable formulas, Make scenarios, and maybe a spreadsheet that calculates commissions. When something breaks, the founder does not know which layer owns the bug. Debugging means opening four tabs and comparing timestamps. Every new developer who joins the project has to learn a bespoke topology that does not map to any standard stack.

The ceiling is not a specific automation that fails. The ceiling is the moment the founder realizes the product's logic does not live in any one place, and no single person can hold the whole system in their head.

The Mobile-First UX Ceiling

Softr layouts are responsive. They reflow at breakpoints, images scale, menus collapse. For a marketing site or a read-mostly portal, that is enough. For anything that needs to feel like an app on a phone, it is not.

Softr is not a progressive web app. It will not install to the home screen with an icon that launches into a full-screen shell. It does not cache pages for offline use, so a delivery driver in a parking garage sees a broken page rather than the last-known state. It does not register for push notifications, so your urgent workflow updates have to arrive by email or SMS with all the delay that implies. It does not expose native gestures or haptics, so swipe-to-archive and pull-to-refresh patterns your users learned in real apps do not work.

When a founder says the customers are asking for the mobile app, what they usually mean is one of three things. They want push notifications to pull users back in. They want offline so the app does not fail in the field. They want an installable icon so the app feels like a product and not a bookmark. Softr gives none of those, and no amount of custom CSS will add them. The mobile ceiling is not a polish issue. It is a platform capability issue.

The Airtable API and Scale Ceiling

Airtable's API limits five requests per second per base. Softr batches where it can, and caches for logged-out traffic, but authenticated pages hit the API live. A list view with a hundred records and five blocks can burn through the per-second budget before the page has finished painting. At low traffic you never notice. At a few hundred concurrent users you start seeing slow loads and occasional "too many requests" errors.

The same limit caps your automation fan-out. A Make scenario that updates ten rows at once is ten requests. If three of those run in parallel, you are above the limit and Airtable starts rejecting calls. The fix is to slow everything down with delays, which brings us back to the latency problem from the logic section.

At the data shape level, Airtable bases have per-base record caps that are generous for a spreadsheet and tight for a product. Once a table is in the hundreds of thousands of rows, every view gets slower, and Softr, which reads those views, gets slower with it. Nobody hits this in month one. Founders hit it in year two and are then trying to migrate under load.

The Lovable Plus Supabase Replacement

When we move a Softr app to a real stack, the default we reach for is Lovable on the frontend and Supabase on the backend. The reason is that the two pieces fill the exact gaps Softr leaves open, and neither one requires the founder to hire a full engineering team on day one.

Supabase is a Postgres database with authentication, storage, row-level security policies, and edge functions baked in. Row-level security is the key word. You write policies in the database itself that say a user can only read rows where the tenant-id matches their claim, or can only update rows where the status is draft. Those policies enforce below the UI, not above it. If a malicious client opens the browser console and calls the API directly, Postgres still refuses. This is the thing Softr cannot give you and the thing your enterprise customer is about to ask for.

Edge functions give you a place to put logic. A function runs on the server, has access to secrets, can call Stripe or an AI model, can write back to the database, and can respond in the same request the user made. The "approve" button the founder wired to a webhook becomes a function call, and the user sees the updated state before they finish moving their mouse. Latency drops from seconds to milliseconds, the Make bill goes away, and the logic now lives in one file in one repository that a developer can read.

Lovable is an AI code environment that writes a React frontend against a Supabase backend. The founder describes the screen, Lovable generates the page and the data queries, and the result is a real React app that can ship to Vercel or Netlify. It supports installable PWA behavior, works offline with the right queries, and uses shadcn components that look like a modern product rather than a template. The design freedom is not infinite, but it is well past the Softr block library.

The combination covers every ceiling. Permissions become RLS plus a proper organization model. Logic becomes edge functions. Mobile becomes a PWA with push and offline. Scale becomes Postgres, which handles a million rows before you notice. And the code is yours. If you and WitsCode part ways, the repo is on GitHub under your account, the database is in your Supabase project, and nobody can hold your product hostage.

The CSV Import Migration Playbook

The migration we run looks simpler than founders fear. The data path is the calmest part. Every Airtable table has a download-as-CSV option in the grid view. You export each table, open Supabase's SQL editor or the table import UI, and load the CSV into a new Postgres table with the same columns. Primary keys get generated, foreign keys get rewired by matching names or ids. A base with fifteen tables is usually imported inside an hour.

Once the schema is in Supabase, we write the row-level security policies before any frontend is pointed at it. This is the step that is tempting to skip. Do not skip it. RLS policies written on day one are trivial. RLS policies written after a month of production traffic are a nightmare because every query has been trained on an unsecured table.

Next we rebuild the UI in Lovable against the new database. For most Softr apps this is four to ten pages. Lovable generates them in hours, not weeks, and each page gets reviewed for permissions, edge cases, and design polish. We keep the same page URLs where we can, so links in customer emails still work.

Cutover is a DNS move or a redirect from the Softr custom domain to the new host. We keep the Softr app live in read-only mode for a week as a fallback, with a banner telling users the new address. Airtable stays around as a reporting tool if the ops team still likes it, syncing from Supabase on a schedule, but it is no longer the system of record.

The whole project, for a typical Softr app, takes two to four weeks end to end. > If your Softr app is already hurting, WitsCode runs this migration as a fixed-scope engagement. We hand you a Lovable repo and a Supabase project that you own.

When to Stay on Softr

Not every Softr app needs to leave. If your product is an internal tool for twenty staff, a public directory, a simple member portal, or a read-heavy experience on top of a CMS-style Airtable base, Softr is the right tool and moving would waste money. The migration conversation starts when the permissions model, the logic layer, the mobile story, or the data scale stops fitting. If none of those are biting, keep shipping on Softr. The ceiling only matters when your product is pressed against it.