This is a placeholder post written in the voice and structure we'll use for real case studies. Replace bracketed sections with real client details (or anonymize). See /blog/_template.html for the empty template.
The setup
[Client] runs a [N]-staff clinic. Two years ago they adopted [VerticalSaaS] because everyone in the industry uses it. Six months in, they were already paying for two add-ons. A year in, they had a dedicated team member doing nothing but workarounds. The bill: $1,400/month, climbing. The pain: half their workflows still didn't fit.
The owner reached out asking for "another SaaS that's better." The honest answer was: at this point, a custom build pays back in 14 months and you stop bending.
The process map (half-day session)
Before we wrote any schema, we spent four hours on Zoom mapping every entity in the business. Patients. Appointments. Treatments. Plans. Invoices. Insurance claims. Practitioners. Rooms. Equipment. The relationships between them — who owns what, who can see what, what triggers what.
This is the work most agencies skip. They jump to "we'll customize HubSpot" without understanding why HubSpot's data model is precisely the wrong shape. The map was the deliverable that justified going custom.
Schema first, UI second
Week one: Postgres schema, Supabase setup, basic auth and roles. No UI yet. We modeled the data correctly before drawing a single button. By Friday of week one, you could create a patient via API and the appointment, claim, and billing relationships all tied together correctly.
This sounds boring. It's the difference between a system that holds up at year three and one that needs a rewrite at month nine.
Week two: UI + integrations
- Next.js admin UI: patient records, appointment scheduler, treatment plans, billing dashboard.
- Stripe for invoicing and payment links.
- Calendar sync (Google + Outlook) for practitioners.
- Twilio SMS for appointment reminders.
- Insurance claim export in the format their clearing house expects.
Week three: migration + training
Friday demo at end of week two: everyone clicked around. Two days of small revisions Monday-Tuesday. Migration script ran Wednesday — 4 years of patient records, 19,000 appointments, every active treatment plan. Training sessions Thursday and Friday. Go-live Monday of week four.
The Friday-night mistake
Saturday morning, two days after go-live, the founder messaged: appointment reminders weren't going out. Investigation: I'd configured the cron job using server time (UTC), and the migration kept the appointment times in local time without timezone metadata. The 9am reminder for a 10am appointment was firing at 4am EST.
Fixed in 90 minutes. But the root cause was rushing the test plan to make Monday go-live. Lesson: schedule the first 72 hours of production as if you'll be on call. Because you will be.
Results
- SaaS bill: $1,400/mo → $0/mo. Custom system runs on $80/mo of hosting.
- 14-month payback at our build price.
- The workarounds person is now doing patient recall calls instead. Real ROI is here, not in the SaaS savings.
- System is theirs. Repo on their GitHub, deployed on their Cloudflare account, MIT-style assignment in the contract. We could disappear tomorrow.
What we'd do differently
Schedule one extra day of pre-launch testing in QA-like conditions. The mistake was eminently catchable — we just didn't make space for it. Three-week timelines are aggressive on purpose, but the last 20% of testing earns its keep on Saturday morning.
Tired of bending your business around a SaaS that almost fits? Look at Horsiq ERP if you want ready-to-use, or Custom CRM / ERP if your process is what makes you different.