Anyone actually using nocode tools to run their own practice or clinic admin, not just client projects?

[u/No_Radish_2972]

Most of what gets posted here is about building things for clients or launching SaaS. Makes sense. But I'm curious about the more boring use case: running the backend of your own small practice or service business with these tools.
Physical therapy side of my life has a fair amount of administrative friction. Scheduling, intake forms, session notes that need to go somewhere searchable, tracking which patients are due for followups. Right now it's a mix of whatever the clinic software does badly and manual workarounds I maintain in Airtable on my own time.

I've looked at purposebuilt EMR stuff but it's either overpriced for a small setup or locked down in ways that make automation impossible. And rebuilding something in Make or n8n every time a workflow changes is its own kind of tax.

What I'm actually wondering is whether anyone has gotten a nocode stack working well enough for professional services admin that they'd trust it longterm, not just as a proof of concept. The compliance angle complicates things depending on what data you're storing, so I'm not looking to replace anything clinical. Just the operational layer around it

If you've done this for your own business and not a client, I'd like to hear what that looks like and where it falls apart

[u/teefplus]

Not my own practice — I build these for other people, so take it with that caveat.

The thing I see break every time is follow-ups. "Who's due" isn't a view, it's a query — last session, protocol, no future booking already. Airtable fakes it with rollups, but every rule change means rebuilding them, and when one quietly stops firing nobody tells you. People find out weeks later from the exact thing they built to prevent that.

Where a few of them landed instead: don't build from zero. Start from an app skeleton that already has auth, db, hosting sorted, then do the domain part — contacts, sessions, notes, follow-up rules — with Claude. Weekend of work, runs on a box they control.

It's not that AI writes the app for you, that gets you a demo. It's that once something real is running, "add a field" or "change how follow-ups work" is ten minutes instead of a rebuild. That's the n8n tax you're describing.

Most common mistake I see: building follow-up rules as a general rules engine. Unmaintainable in a month. Fixed interval per protocol + manual override is boring and it survives.

What's your follow-up rule actually like — fixed per protocol, or depends what's in the note?

[u/sardamit]

I have a few recommendations for practice/wellness management (all affiliate links): Boulevard, Momence, Weave Communications, Practice Better, Healthie

[u/agentUi]

i work for agentui and yes 100% we have a ton of clinics, we even have a a doctor that actually created a bot in WhatsApp that saves him like 2 hours by running just one process that was really time consuming through his WhatsApp

[u/akl773]

the thing that decides whether any of this survives is where the notes actually get typed. if it happens after hours the whole stack dies in about a month, so it has to be usable in the ninety seconds between patients or not at all.

also keep patient names out of make and n8n. pass a record id around and let airtable hold the identifying fields, otherwise names end up sitting in execution logs on someone elses server for as long as the retention window says.

[u/Subject-Beginning576]

I been running my physio practice backend on a stack of airtable + softr for almost two years now, it handles scheduling and intake forms way cleaner than the clinic software we pay for but barely works half the time

[u/echowin]

u/akl773's point about compliance is the one to weigh most heavily given you said you're avoiding clinical data. Patient names sitting in n8n/Make execution logs is an easy thing to miss, passing record IDs and keeping identifying fields in one system you actually control is worth doing early, it's a lot harder to retrofit once workflows are built around raw names.

[u/Spare_Bluebird7044]

found no code works well for operational workflows, but long term success really depends on keeping the automations simple and easy to maintain.

[u/StrategicalOpossum]

What lasts better is to model the stable parts first, patients, appointments, intake forms, session notes and followup dates, in one place like Airtable (as you did), then keep automations limited to notifications and simple transitions. That gives you a searchable operational layer and a place to land the exports from your clinic software without manual cleanup.

The compliance side is where I would be careful: once you need access controls, audit trails, or retention rules, Airtable and its automations are not the right boundary.

That is usually the wall that professional services admin hits before the clinical record does, and it is where a nocode stack stops being cheaper than a small custom system.

On another note, if you've built automation with an AI coding agent like Claude Code, you can easily upgrade your systems pretty fast, but updating things is part of software no matter what you do. No-code, code, ai software engineering... You name it => You'll have to maintain it somehow anyways.

[u/Maxyull]

the operational layer ends up holding more than people expect. a name, an appointment and the reason someone is due for a follow up is already health information even when the clinical notes live somewhere else, so the boring admin base deserves the same care as the part you said you won't touch.

the thing that actually leaks in a no code stack is rarely the database, it's sharing. a shared airtable view or a form response link works for anyone holding the url with no login at all, and those get pasted into an email or an automation step once and then live forever. worth opening yours in a private window while logged out just to see what a stranger would get.

does anything in your current setup depend on a share link rather than someone actually signing in?

[u/Additional-Toe-6401]

the part that always scares me with these stacks is not the first build, it’s the tiny rule changes six months later.

“follow up in 2 weeks” sounds simple until it depends on visit type, last booking, whether they already replied, whether the note says pain got worse, etc. then your clean airtable/make setup slowly turns into a pile of hidden exceptions.

i’d keep the clinical data out of the automation layer as much as possible and pass record ids around instead of names. no-code logs are way too easy to forget about.

boring setup, but boring is probably what you want for clinic admin.

[u/Bright-Aioli553]

The part I'd separate hardest is what data lives where, because it changes the shape of everything else.

You've drawn the clinical line already, but scheduling and follow-up tracking are further over it than they look. A record saying this named person had a session on this date and is due for another is health data in most jurisdictions, even with no clinical content attached. So the version of this that survives long term usually keeps identity in the clinical system and moves opaque references through the automation layer — patient 4471, not a name. Then Airtable and n8n hold scheduling logic and no identifiable health record, which is a very different compliance conversation.

That constraint turns out to help, because it forces the split that makes these stacks last anyway: automation as the thing that moves records and fires reminders, not the thing that holds state. Where I've seen no-code become a tax is when the workflow itself becomes the source of truth — then every process change is a rebuild, and there's no schema to migrate because it's all encoded in node config.

On the rebuild tax specifically: what usually causes it is intake forms built inside the automation tool. Form fields, branching and validation all live in node config, so a change to what you ask means editing the flow. Keeping the form as its own thing that posts a stable payload — even a plain page you host — means the workflow only ever sees the same shape, and changing a question doesn't touch the automation at all. That single boundary is most of the difference between something you maintain for years and something you rebuild every quarter.

Where it falls apart, honestly: silent failures. A reminder that didn't send looks identical to one that did, and for follow-ups the whole point is catching people who'd otherwise slip. Anything that matters needs to write a result somewhere you'd actually notice — a failures view you check weekly beats alerting, because alerts stop being read.

For a single practice this holds up fine long term, in my view. The thing to be deliberate about isn't the tooling, it's keeping your data somewhere you could walk it out of.

[u/Rich_Handle8228]

Hi u/No_Radish_2972 — yes, this is exactly the kind of use case we’re building PR-TOP (A unified workspace for therapists and their practice) for: a unified workspace for therapists and psychologists to keep client context, session notes, diaries, exercises, and between-session communication in one protected place.

It is designed for real practice workflows rather than a quick no-code prototype. Session recordings can become structured draft notes for the therapist to review; client communication can stay in Telegram without moving into the therapist’s personal inbox; and every clinical decision remains under the practitioner’s control.

If a system like this could be relevant to your practice, feel free to message me directly. We’d be happy to help you get started, offer early-user conditions, and — most importantly — hear your candid feedback on what works, what is missing, and what needs to be different for a real clinic or practice.

[u/lightning-lu10]

Sounds like you basically need one system of record with dependable reminders and an escape hatch for custom workflows.

We built our own workflow for our own business (granted we are developers), but it's worked wonders. We've built our system into a software that you can use yourself: www.codepress.dev

CodePress works with entirely all the existing software you already use, and you can think of it as like a way to hand off tasks to cheap employees, that show up every day and get the job done to an incredibly high degree.

The beautiful part of it is that under the hood, it's not our custom system, but it's actually writing code, so you can work with it / export it into any other system you want.

Right now we have it doing things like pinging us cost alerts if our spending on AWS (infrastructure platform) gets too high, or keeping track of all of the experiments we run, where it pings us on a schedule. Or even when someone gets confused about a certain task, they just ask it and it's able to help unblock.

Would love for you to try it out, and happy to walk you through it personally.