Jordan: So it's a Tuesday night — maybe eleven thirty — and my phone buzzes. It's Marcus. He runs a logistics brokerage, one of my retainer clients. And the text just says, "Jordan, the invoice sync is doing something weird. Can I just turn it off?"
Can I just turn it off. Five words. And I'm staring at this message thinking — no. No, you can't. Because the only way to turn it off is for me to log into Make, find the scenario, flip the toggle, and then remember to flip it back in the morning. And if I forget, his invoices don't sync for a day and his ops team thinks the system is broken.
So I do what I always do. I text back "on it," open my laptop in bed, pause the scenario, set a reminder for seven AM, and go to sleep annoyed.
But here's what actually bothered me. It wasn't the interruption. It was that Marcus was asking for something completely reasonable — a way to see what his automations were doing and a switch to pause them when something felt wrong — and I had given him nothing. No dashboard. No toggles. No proof that anything was running correctly. Just... trust me, it's working.
That's the client proof problem. And I spent the next day building something that fixed it — not a product, not a custom app, just a thin control surface. Took me about four hours. And it changed how Marcus talks about my work to other people.
Jordan: By the end of this episode you'll have a working client portal — on/off toggles, SLA status chips, recent run timestamps, and a kill switch — built on Airtable and Softr with Make handling the wiring. Total build time under a day. Total cost under a hundred and forty dollars a month. And if Softr isn't your thing, I'll walk through a Notion plus Super fallback for clients who only need to see, not touch. This is Headcount Zero. I'm Jordan.
Jordan: So let me back up and explain what I mean by a control surface, because it's not a portal. Not really. When most people hear "client portal Airtable," they think of a full-blown app — project management, file sharing, messaging, the works. Softr's own landing page sells it that way. Airtable has a whole Portals product now. And there are vendors like miniExtensions and CollabPortals that will build you something polished for a monthly fee.
That's not what we're building. What we're building is the thinnest possible layer between your client and the automations you run for them. Three things. One — toggles. On/off switches the client can flip themselves without texting you at midnight. Two — proof chips. Little status indicators that show the last time something ran, whether it met the SLA, and whether it succeeded or failed. Three — a panic switch. A kill switch the client can hit if something goes sideways, and it actually stops the downstream automations from firing.
That's it. No project management. No file uploads. No chat. Just proof and control. Because those are the two things clients actually lose sleep over — is it working, and can I stop it if it's not.
And the reason I call it a control surface instead of a portal is because the word portal sets the wrong expectation. A portal sounds like a product. A control surface sounds like what it is — a dashboard bolted onto the side of your existing stack. You're not building a new thing. You're exposing a window into the thing you already built.
Jordan: Okay. The stack. Airtable is the system of record — it holds the client data, the toggle states, and the metrics. Softr is the front end — it gives your client a login, shows them their toggles and status chips, and lets them click buttons that actually do things. And Make is the glue — it receives the button clicks from Softr via webhook, checks the rules, and updates Airtable.
Why these three? Because I already had Airtable running for Marcus. His automations were already writing to Airtable tables. So the data was there — I just wasn't showing it to him. Softr connects directly to Airtable as a data source, and its Call API action — available on the Professional plan and above — lets a button send a POST request to any webhook. That's the whole trick. Client clicks a button in Softr, Softr fires a POST to a Make webhook, Make checks the rules and updates Airtable, and the Softr page refreshes to show the new state.
The round trip is fast. I haven't published formal latency benchmarks yet — that's coming in a live doc on the build page — but in practice, the toggle state updates in Airtable within a few seconds of the click. Fast enough that the client sees the change before they wonder if it worked.
Jordan: Now — Airtable schema. This is where most people get stuck, so I want to be specific. Three tables. First table — Clients. Primary field is the client name. You need a Client ID field, which is just a formula that returns the record ID. You need a Portal Emails field — this is how Softr knows which logged-in user sees which client's data. And you need a Panic Switch field. That's a checkbox. When it's checked, every downstream automation for that client stops.
Second table — Toggles. One row per controllable switch. So for Marcus, I had three toggles — invoice sync, weekly report, and lead notification. Each row links back to the Clients table, has a Current State field — single select, on or off — and has Last Toggle At and Last Toggle By fields. Those are Airtable's built-in Last Modified Time and Last Modified By field types, configured to watch only the Current State field. That's important. You don't want every edit to the row updating those timestamps — only actual state changes.
Third table — Metrics. This is where your proof chips live. Each row links to a client and tracks an SLA target in minutes, the last run timestamp, and a run status — okay, degraded, or failed. And then you add a formula field — I call it SLA Chip — that compares the time since the last run against the SLA target and returns a green, yellow, or gray indicator. If you want the exact field names and formulas, grab the Control Surface Build Checklist on the Resources page — every field is named exactly as I'm describing so your mappings work the first time.
Jordan: Alright — Make. You create a custom webhook in a new scenario. I name mine toggle underscore event. The critical piece here is a shared secret header. You set up the webhook to require a header — I use X-HCZ-Secret — with a value only you and Softr know. That way random POST requests from the internet don't flip your client's automations.
The scenario logic is short. First module — search the Clients table for the client ID that came in the payload. Second — a router. Route A checks the Panic Switch field. If it's checked, the scenario returns a four twenty-three Locked response and stops. Nothing happens. The client sees an error message in Softr that says the system is locked — contact your admin. Route B — if the panic switch is off — updates the Toggles table. Flips the Current State, writes the reason from the payload into an Audit Reason field, and returns a success response.
That's roughly twelve minutes to set up if you've done a Make webhook before. Maybe twenty if you haven't.
One thing to know about Make webhooks — they enforce a rate limit of three hundred requests per ten-second interval. If you somehow exceed that, you get a four twenty-nine. For a client portal where someone is clicking a toggle button, you will never hit that limit. But it's worth knowing it exists if you're building for a client with a large team.
Jordan: Now — Softr. You connect your Airtable base as a data source, and you set up two user groups — Admin and Client. Your email goes in Admin. Your client's email goes in Client. Page-level and block-level visibility controls let you show different things to different groups. So the client sees their dashboard — their toggles, their SLA chips, their recent runs. You see everything — all clients, all toggles, plus the Panic Switch status for each client.
The toggle button itself uses Softr's Call API action. You configure it to POST to your Make webhook URL with the secret header and a JSON body that includes the client ID, the toggle record ID, the desired state — which flips from the current state — and the logged-in user's email. That last part matters for the audit trail. When Marcus flips a toggle, the payload includes his email, and the Audit Reason field in Airtable records that it was a client-initiated change from the portal.
And here's the part that surprised me. The proof chips — the SLA status, the last run timestamp, the green or yellow indicator — those did more for client trust than the toggles did. Marcus told me, and I'm quoting him, "I used to wonder if your stuff was actually running. Now I just look." That's the whole value proposition in one sentence. He doesn't need to text me. He doesn't need to trust me. He can see it.
The Last Modified Time and Last Modified By fields in Airtable are doing the heavy lifting here. Every time a Make scenario updates a metric row — writes a new run timestamp, updates the status — Airtable records when it happened and who did it. If the update came through Make, the modifier shows as Automations. If it came through the portal, it shows the service account. Either way, there's a visible, timestamped record.
Jordan: Now — I promised a fallback, and here it is. If your client doesn't need toggles — if they just need to see that things are running — you can skip Softr entirely and use Notion plus Super. You build a Notion page with embedded database views showing the Metrics table, publish it through Super with their Memberships feature for login protection, and you're done. No webhook wiring. No Call API. Just a read-only window into your Airtable data synced through a Notion integration.
The tradeoff is obvious — no write-back capability. The client can look but can't touch. For some clients, that's fine. For Marcus, it wasn't enough. He wanted the switches.
Jordan: Okay — the counterargument. And it's a real one. If your client's IT team requires enterprise single sign-on — SAML or OIDC through their identity provider — Softr can't do that below the Enterprise plan. OpenID SSO is Enterprise only. And if you're building for a client with strict role-based access control requirements or multiple data sources, tools like Retool or Glide might be better long-term choices. Retool's Business tier includes portals and embedded apps with external user pricing — first fifty users free, then per-user fees above that — and SSO on Enterprise. Glide Business at a hundred and ninety-nine dollars a month annual includes Call API and webhook triggers, but again, SSO is an Enterprise add-on.
So yeah — if procurement hands you an SSO requirement on day one, Softr Professional isn't the answer. I covered exactly how to wire up SSO with Auth0 and Clerk back in episode three.
But here's why I still start with Softr. The Airtable schema doesn't change. The Make webhooks don't change. The data model is the same regardless of which front end you bolt on. So you ship the Softr control surface this week — your client gets proof and toggles immediately — and if six months from now their IT team requires SSO, you port the front end to Glide Enterprise or Retool without rethinking the core architecture. The expensive part of a portal is the data model and the automation logic. The front end is the cheap part. Softr just happens to be the fastest cheap part I've found.
As of May twenty twenty-six, Softr Professional runs a hundred and thirty-nine dollars a month. That gets you a hundred app users, ten thousand workflow actions, and three custom user groups. For most solo-run client portals, that's more than enough. If you need more users or unlimited groups, Business is two sixty-nine a month. Check the live pricing doc linked on the build page — these numbers shift.
Jordan: Last piece — testing. Before you invite your client, you need to run a functional sweep. Create a test client with two toggles. Log in as a Client user. Click the toggle button — on to off, off to on, twice each. Go back to Airtable and verify that Current State flipped correctly, Last Toggle At updated, and Last Toggle By shows the service account. Then flip the Panic Switch on. Try the toggle again. You should see an error in Softr and no change in Airtable. Uncheck the Panic Switch. Confirm everything works again.
For latency, I'd recommend running ten to twenty toggles while logging three timestamps — the click time, the Make webhook receive time, and the Airtable Last Modified Time. Compute the median and the ninety-fifth percentile. I haven't published those numbers yet for this specific stack — that data is coming in the live doc — but directionally, you're looking at low single-digit seconds for the full round trip. Fast enough that the client doesn't notice.
Jordan: So — Marcus. After I shipped the control surface, he stopped texting me at night. Not because the automations stopped having issues — they didn't, things still break sometimes — but because he could see for himself when something was off, and he had a switch to pause it until morning. That changed the relationship. He went from "I hope Jordan's stuff is working" to "I can see that it's working." And he referred me two clients in the next month. Both of them asked for the same thing — a dashboard with toggles.
Turns out, making invisible work visible is the best sales tool I've ever built. And it took four hours.
If you want to build this yourself, start with the Airtable schema. Three tables — Clients, Toggles, Metrics. Get the fields right first, then wire Softr and Make on top. One afternoon. That's the whole build.
I'm Jordan. Ship it solo.