How I built the backend behind a real wellness clinic.

Your intro to EmpowermentHub.

EmpowermentHub is a web-based management system for a wellness clinic running coaching and consultation appointments. It does the unglamorous work of running a small services business so the owners can stop running it from a spreadsheet and a Gmail inbox.

Built on CakePHP 4, MySQL, and Bootstrap, with a couple of extras layered in where the brief demanded them.

• Booking & calendarClients book. Coaches review. Admins triage. Nobody double-books.
• InvoicingGenerate, track, export to XLSX so the accountant stays happy.
• Email automation24h appointment reminders. Overdue-invoice nudges. Quietly running on CRON.
• Auth & rolesAdmins, coaches, clients — each seeing exactly what they should and nothing else.
• Public siteContact form, reCAPTCHA, services pages. The front door visitors actually walk through.

While the rest of my team handled design, the public-facing site, and frontend polish, I was deep in the backend wiring it all together.

The thing that nearly killed me.

The calendar.

Every wellness business runs on the calendar. If a client double-books, a coach loses their hour, an admin spends twenty minutes on the phone untangling it, and the trust starts cracking. So the booking system had to be airtight.

“Get the calendar wrong and the whole thing falls apart. Get it right and nobody notices it’s there.”

I designed it from scratch — the schema, the state machine, the conflict checks. Four appointment statuses (available, booked, completed, cancelled), each with rules about who can transition it where. Filterable by coach, by service type, by date range. Real-time availability that doesn’t lie.

There was no shortcut on this one. No off-the-shelf calendar widget would do, because none of them understand what a coach’s availability means or how to express “this slot is held but not yet confirmed.” So I wrote it. Three weeks on the data model alone before a single feature shipped on top — and I’d do it again.

What’s under the hood.

Backends rarely get to be glamorous. This one isn’t. It’s careful, boring, and it’s the careful-and-boring kind that lets the rest of the team build features without things falling over.

I designed the entire MySQL schema — clients, coaches, appointments, invoices, services, contact submissions — with foreign keys, indices on the read-hot paths, and migrations checked into git. CakePHP 4 on top, MVC-shaped, PSR-12 lint-clean.

Auth is CakePHP’s middleware with my own role-based authorization layer over it — admins see invoices, coaches don’t. CSRF on every form. Sessions timeout. Passwords hashed. The boring stuff that nobody notices when it’s right and everybody notices the second it isn’t.

Invoices export to XLSX through PHPSpreadsheet — the client’s accountant asked for that specifically, so we shipped it. CRON jobs fire 24h-out reminders and overdue-invoice nudges, idempotent so a re-run doesn’t double-send. The contact form sits behind Google reCAPTCHA with rate limiting on the server side, because public forms attract bots within hours.

Teamwork makes the dream work.

Five of us, one client, sixteen weeks. I owned the backend. Two teammates handled the frontend and the public site. One did the design system. One led client communication and project management.

What I learned was that the backend is only as useful as the contract it presents to the people building on top of it. So I spent the first three weeks just on the database design and the API surface, before writing a single feature. Once the contract was right, the rest of the team could fly — nobody waiting on me to clarify what an appointment object looked like or which endpoint returned what.

It also meant the few times the schema needed to change mid-project, the cost was visible and bounded, not creeping through every layer of the app.

A walk through the app.

A few of the screens admins, coaches, and clients live in every day. The boring stuff, beautifully.