One file. No build step. Ten sections and the photography inside it.
A demonstration build for a dental and diagnostic centre in Tundla, put together to show the practice what its site could be. The interesting constraint was delivery: the whole thing is a single HTML document with the clinic photography embedded in it, so it runs from any host — or from a USB stick — with nothing to install.
Dr. A.K Gupta Dental & Diagnostic Centre, captured from the demonstration build at ak-dental-demo.netlify.app.
System pipeline
DeliverSingle document
PersuadeHero
RouteWhatsApp click-to-chat ×6
CaptureName
section handoff
The problem
What the build had to solve.
01
The practice pairs a dental clinic with an in-house OPG imaging centre — a real differentiator that no template accounts for.
02
A demonstration has to survive being forwarded, opened on a phone, and viewed with no explanation attached.
03
Patients in the catchment reach a clinic by phone or WhatsApp, so every screen had to offer both without scrolling back.
section handoff
Architecture
How an enquiry moves through it.
Deliver
Persuade
Route
Capture
1
Deliver
The build is one HTML document with styles, scripts and photography embedded, so there is no asset pipeline and nothing to break when it is moved between hosts.
Single document
Inlined CSS
Base64 photography
2
Persuade
Ten sections take a visitor from the treatment they searched for to the clinician who provides it, with the in-house diagnostics centre given a section of its own.
Hero
Services
In-house diagnostics
Gallery
Location
3
Route
Click-to-chat and direct-dial links repeat through the page, so the contact action is always within reach of the section that prompted it.
WhatsApp click-to-chat ×6
Direct dial ×6
Booking form
4
Capture
An in-page appointment form takes the name, a telephone number and a preferred date, so an enquiry can be left outside calling hours.
Name
Telephone input
Date picker
section handoff
The build
What it is made of.
Every row was read off the running deployment, not from a project brief. Open the site and view source to check any of it.
Delivery
Static HTML, single document — 429,734 bytes
Hosting
Netlify
Photography
5 clinic images base64-inlined (379 kB, 88% of the document)
Typefaces
Inter, Playfair Display (Google Fonts)
Motion
GSAP; three.js r128 via cdnjs
Contact channels
WhatsApp click-to-chat, direct dial, in-page appointment form
Structured data
None — see the decisions below
section handoff
Engineering decisions
The choices, and why they went that way.
The photography is inside the document, and that is a trade, not a free win
Embedding the clinic images as base64 makes the build a single portable file: it opens from any host, any folder, or an email attachment, with no broken image paths. The cost is real and worth stating — 379,084 bytes of the 429,734-byte payload, about 88%, is images that a browser cannot cache separately, cannot serve responsively, and must download before the page is complete. For a demonstration that gets forwarded, portability won. For a production build it would not.
Verify: View source: five img elements carry src="data:image/jpeg;base64,…". The remaining four are Unsplash URLs standing in as placeholders.
The diagnostics centre gets its own section rather than a service row
In-house OPG imaging is the reason a patient would choose this practice over the one nearer to them — it means the scan and the treatment happen in one visit. Listing it as a sixth bullet among treatments would have buried the single thing that is not interchangeable.
Verify: The services section carries a dedicated “Vedika OPG Centre” entry under an “In-House Diagnostics” heading.
Contact repeats six times instead of sitting in a header
On a phone, a sticky header costs vertical space on every screen of a long page. Repeating the WhatsApp and dial links at the end of each persuasive section instead puts the action next to the reason for taking it, and costs nothing when the visitor is not ready.
Verify: Six wa.me links and six tel: links appear through the document, one pair per major section.
No structured data, and it is a gap rather than a decision
The Saraswati build publishes a full Dentist entity graph; this one publishes none, and has no meta description either. Naming it here rather than quietly omitting the row is the point: this is a demonstration of the visual and conversion layer, and the discoverability work that a production clinic site needs was not part of it.
Verify: View source: the document contains no application/ld+json block and no meta name="description".
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 AK Dental site a client project?
No. It is a demonstration build — SheetFlow made it to show the practice what its site could be, and it is published here on that basis. It is unambiguously our work, deployed from our own Netlify account, but no fee, brief or agreement sits behind it and no commercial relationship is implied.
Why is the AK Dental build a single 429 kB HTML file?
So it survives being forwarded. Everything — styles, scripts and five clinic photographs — is embedded in one document, which means it opens correctly from any host, any folder, or an email attachment with no broken paths and nothing to install. The trade is that about 88% of that payload is images the browser cannot cache separately or serve responsively, which is acceptable for a demonstration and would not be for a production build.
What business results has the AK Dental build produced?
Not publicly disclosed, and in this case there are none to disclose. It is a demonstration that was not commissioned, so there is no engagement behind it and no outcome has been measured or claimed.
