Case Study: A Patient-Acquisition Engine for Aesthetic Clinics
How we built Palyri: a multi-tenant platform that captures a clinic's leads the instant they arrive, routes them to the right person, and runs the whole appointment pipeline, from ad click to treatment, in one system.
An aesthetic clinic runs on a simple chain of events: someone sees an ad, fills in a form, gets a call, books a consultation, shows up, and buys a treatment. Every clinic we looked at was paying real money to start that chain on Meta and Google. Almost none of them could run it as one connected process. Leads landed in a Facebook inbox, reception called when they had a free minute, the appointment book lived in a separate tool, and the ad spend lived in a third. The chain existed, but nothing held it together.
We built Palyri to hold it together. This is not a story about a marketing result; it is a story about how the system is built and why we built it the way we did. Palyri is a multi-tenant platform that captures a clinic's leads the second they arrive, gets them to the right person fast, and runs every stage of the appointment pipeline, from ad click to treatment, in one place.
The problem we set out to solve
The problem was never a shortage of leads. It was that the pieces never connected, so work fell through the gaps.
So the brief was narrow and clear: take the messy, multi-tool reality and turn it into one pipeline a clinic's front desk could actually run, without changing how the ads were bought or who answered the phone.
One pipeline: how a lead flows
The core of Palyri is a single pipeline that a lead moves through, with every stage recorded as it happens. The design principle is that nothing is reconstructed later from memory or a spreadsheet. The lead arrives with its source attached, gets routed, claimed, called, booked, secured with a deposit, and its outcome recorded, all as states on one record.
The value of modelling it this way is that the clinic stops losing information at every handoff. The rest of the build is really about making each of these stages fast and reliable.
Capturing leads the instant they happen
The first job is to never lose a lead and never let one go cold. Palyri ingests a Meta lead the moment the form is submitted through a Lead Ads webhook, with a native polling fallback that sweeps for anything a webhook might have missed, so a dropped notification never means a lost patient. Google, Instagram and manually entered leads flow into the same table, each tagged with its source. On the way in, the system deduplicates, attributes the lead to its campaign, and records the separate marketing and data-processing consents the Polish market requires.
Getting the lead called, by the right person
Capturing a lead is worthless if it sits unseen. The second the lead lands, Palyri pushes a card to the clinic's front desk over a Telegram bot, with the lead's details and one-tap status buttons, because that is where reception already lives all day. To stop two people calling the same person, a setter claims the lead, and the claim is held with an expiry so a lead can never get permanently stuck to someone who walked away from their desk. This claim-and-expire model is small, but it is the difference between a tidy queue and chaos when several people work leads at once.
Securing the appointment
The most expensive event in this business is the no-show: a booked slot that produces nothing and blocks a paying patient. Palyri builds the fix into the pipeline. When an appointment is set, the lead is sent a link to pay a small refundable deposit that secures the slot, and the system tracks that deposit through paid, transferred-to-treatment and waived states. We built deposits in as a first-class stage rather than a note in a comment field, because it is the single mechanism that does the most to protect the clinic's calendar.
Built for agencies, isolated per clinic
Palyri is multi-tenant by design. A marketing agency can run many clinics from one platform, and every clinic's data is isolated from every other through row-level security on every query. That shaped a lot of the engineering: one schema, strict per-clinic boundaries, and integrations that are configured per clinic rather than globally.
Under the hood
Palyri is a custom application, not a pile of SaaS subscriptions wired together.
- Next.js and PostgreSQL (Supabase), multi-tenant with row-level security. One schema, strict per-clinic isolation on every query, with an agency layer on top.
- Instant lead capture. A Meta Lead Ads webhook ingests each submission as it happens, with a native polling fallback so a misfired webhook never loses a lead. Google, Instagram and manual entries share the same pipeline with their source preserved.
- A Telegram bot for the front desk, pushing lead cards with one-tap status buttons, plus a setter claim-and-expire model so two people never work the same lead.
- Deposits as a first-class stage, tracked through paid, transferred and waived states, to defend the calendar against no-shows.
- An idempotent messaging outbox. SMS confirmations, deposit reminders and follow-up sequences are scheduled and de-duplicated, and every send is consent-gated, with separate SMS, email and phone consent stored on each lead.
- Ad-spend sync, pulling Meta and Google figures on a schedule so spend and outcomes live in the same system instead of separate tabs.
- A per-clinic performance digest delivered to Telegram and email, on top of a full event log of more than 205,000 records that gives every action an audit trail.
Why weeks, not quarters
A platform this complete usually sounds like a year of work. It is not, because the build follows the same process we use on every project: a tight scope, an agent-assisted build, and a deployment that is monitored from day one. We break the method down in how we ship custom apps in weeks, and the build-versus-buy logic in build vs buy: when a custom app wins.
What we would tell any clinic considering this
A few honest lessons from the build.
- Connect the chain before you optimise it. Most clinics try to fix conversion before they can even see the full path from ad to treatment. Make the pipeline whole first; the visibility alone changes how the team works.
- Speed of first contact is an engineering problem. Instant capture and a card on the front desk's phone do more than any clever script, because the fastest call usually wins.
- Design the boring states deliberately. Claim-and-expire, deposit paid-or-waived, consent per channel. None of it is glamorous, and all of it is what makes the system trustworthy when real people use it all day.
If your clinic is buying ads but running the rest on a Facebook inbox and a spreadsheet, talk to us. We will look at how your leads actually flow today and show you what one connected pipeline would change before we build anything.