The second clinic build is where you find out what was a template.
Built after the single-file demonstrations, and deliberately not like them. Every clinic-specific fact — name, address, treatments, hours, contact links — sits in one typed module, separate from the fourteen components that render it. Re-pointing the system at a different practice is a data edit, not a rebuild.
Healthcare · demonstration build · Built as a sales demonstration
System pipeline
ModelTyped clinic data module
ComposeHeroSection
RouteWhatsApp link
ReachFloating WhatsApp button
section handoff
The problem
What the build had to solve.
01
A third clinic build in the same sector is where copy-paste stops being cheaper than structure.
02
Clinic facts — hours, address, treatment list, contact numbers — are exactly the content that goes stale, and they were scattered through the markup of the earlier builds.
03
The practice presents itself as a premium, multi-speciality clinic, so the interface had to carry that without stock-template styling.
section handoff
Architecture
How an enquiry moves through it.
Model
Compose
Route
Reach
1
Model
One typed module holds every clinic-specific fact — identity, address, hours, treatments, gallery, testimonials and the contact links built from the number.
Typed clinic data module
Service type
Testimonial type
Gallery image type
2
Compose
Fourteen section components read that module and know nothing else about the practice, so none of them has to change when the practice does.
HeroSection
ServicesSection
TrustSection
BookingSection
ContactSection
3
Route
Contact actions are derived from the single stored number rather than written per link, so one edit changes every call, chat and directions target on the site.
WhatsApp link
Call link
Directions link
4
Reach
A floating WhatsApp control and a sticky booking action persist as the visitor scrolls, so the two actions that matter are never more than a tap away.
Floating WhatsApp button
Sticky booking button
section handoff
The build
What it is made of.
Every row was read off the deployed build at inspection, not from a project brief; the decisions below give the date each was checked. The deployment is not linked, because the business is not named.
Framework
React (SPA) on Vite
Language
TypeScript, strict project references
Styling
Tailwind CSS
Motion
framer-motion
Icons
lucide-react
Source size
About 1,300 lines across 20 files — 14 section components, one data module
Hosting
Static hosting
section handoff
Engineering decisions
The choices, and why they went that way.
Clinic content is a typed module, not markup
The recurring failure in clinic sites is stale detail — an old number, last year’s hours, a treatment no longer offered — because those facts are scattered across the markup and only some get updated. Putting them in one typed object makes the update a single edit, and makes a missing field a compile error rather than a blank space on a live page.
Verify: The clinic data lives in one typed module of about 160 lines, exporting the service, testimonial and gallery types alongside the clinic object the components consume.
Contact links are derived from the number, not written beside it
A clinic that changes its phone number changes it once. Storing the number and building the wa.me, tel: and Maps targets from it removes the class of bug where the header dials the new number and the footer dials the old one.
Verify: The WhatsApp, call and directions links are all built from one stored phone number and one stored map query.
Fourteen small components rather than one page file
The earlier clinic demonstrations were single documents, which is the right call for something that gets forwarded and the wrong one for something that gets extended. Sections that are separately named and separately typed can be reordered, dropped or reused for the next practice without reading the whole file.
Verify: src/components/ holds 14 .tsx files; App.tsx is 38 lines and does nothing but order them.
The Google rating on the page is the clinic’s, and is not ours to claim
The build renders a rating and a review count taken from the practice’s own public Google listing. That is the clinic’s data, displayed on the clinic’s own site as it would be anywhere else. It is not a SheetFlow outcome metric, and it is not offered here as evidence of anything we did — which is why no figure from it appears on this page.
Verify: The values originate in the practice’s public Google Business listing, stored in the data module as a rating and a review count.
section handoff
Business outcome
What we can prove, and what we cannot.
Not publicly disclosed.
No business outcome has been measured against a stated method and confirmed with this client, so no figure is published. We would rather show you the system and let you judge it than print a number nobody verified.
section handoff
Questions
About this project.
Is the multi-speciality clinic site a client project?
No. It is a demonstration build, made to show a practice what its site could be and published here on that basis. The source is ours and it is deployed from our own hosting account, but it was not commissioned and no commercial relationship is implied. The practice is not named and the build is not linked.
Why is this build structured differently from the other clinic demonstrations?
Because it is the third one. The single-file builds are portable and ideal for something that gets forwarded, but every clinic-specific fact is embedded in the markup, so re-pointing one at another practice means editing prose in a 400 kB document. Here the practice details live in one typed module that fourteen components read, which makes the same job a data edit — and makes a missing field a compile error instead of a gap on a live page.
What business results has this demonstration build produced?
Not publicly disclosed, and none exist to disclose. It is an uncommissioned demonstration, so there is no engagement behind it and no outcome has been measured or claimed. The rating shown on the build itself is the practice’s own public Google listing data, not a result of ours.
