FaceBar
FaceBar’s clinic platform — an Angular public site with online booking, a staff dashboard for appointments and requests, and an ERP-style client and payment ledger, delivered end to end with localization and a Docker/Nginx pipeline.
My Role
Tech Lead — architecture and delivery of the full platform: the Angular booking front end, the staff dashboard, ERP-style client management with payment accounting, localization, deployment, and client communication.
Project Type
Client Project — a growing aesthetic clinic’s marketing site, online booking, and internal operations in one system.
Tools Used
Angular, TypeScript, online booking engine, staff dashboard, ERP-style client & payment accounting, i18n, Docker, Nginx, custom CI/CD
Live Link
https://facebar.ge
Problem & Solutions
Modeling a Clinic’s Catalog
Problem
Dozens of treatments, the devices behind them, and the specialists who perform them — related data that a flat page structure kept duplicating and letting drift out of sync.
Solution
Treatments, technologies, and specialists became linked entities in the CMS; catalog pages, filters, and booking options are generated from the relationships.
Booking That Staff Can Actually Run
Problem
Online booking is only useful if the front desk trusts it: double bookings, unconfirmed slots, and lost requests turn a feature into a liability.
Solution
A staff dashboard sits on the same booking data — appointments, requests, and confirmations in one queue — so the online calendar and the front desk never disagree.
Payments and Client History in One Place
Problem
Client records, visit history, and payments lived in separate tools, so every question about a client meant three lookups.
Solution
An ERP-style client module keeps visits and payment accounting on one record, giving the clinic a single source of truth and reporting without exports.
Architecture
One Angular front end for patients, a staff dashboard on the same booking data, and an API that owns availability, client records, and payment accounting.
Decision log
The calls that shaped the build — what was decided, why, and what it cost.
Treatments, technologies, and specialists as linked entities
Decision. Model the clinic's catalog as related content types instead of standalone pages.
Context. Flat pages duplicated the same equipment and specialist details across dozens of treatments and drifted out of sync.
Consequence. Catalog pages, filters, and booking options are generated from the relationships; an edit happens once.
The staff dashboard reads the same booking data
Decision. Build the front-desk dashboard on the booking records rather than syncing to a separate calendar tool.
Context. Online booking is only trusted if the front desk cannot be surprised by it.
Consequence. The online calendar and the front desk never disagree. More scope for the team, but no integration to babysit.
Client ledger inside the platform
Decision. Keep client records, visit history, and payment accounting in one module.
Context. Every question about a client meant three lookups across three tools.
Consequence. A single source of truth and reporting without exports. The platform became an operations system, so backups and uptime became first-class requirements.
A Treatment Catalog Built for Booking
Treatments, technologies, and specialists are structured data, so every catalog page ends in a booking action instead of a phone number.
Equipment as Content
Each treatment links to the medical technology behind it; the clinic maintains both from the same CMS, and the site cross-references them automatically.
From Browsing to a Confirmed Slot
The booking flow checks availability, captures the client, and lands in the staff dashboard — the same record the ERP side bills against.
Growth & Outcome
Patients discover treatments and book online, staff manage appointments and client records from one dashboard, and payments are accounted in the same system — one platform where a website, a booking widget, and spreadsheets used to be.
Gallery
