Aligned with the Arkansas State Dental Association — supporting every Arkansas dental clinic.
Field guide · Layers · MMXXVI
What makes a clinic website actually work?
A clinic website isn't one thing — it's four layers stacked on top of each other. Most agencies build the top one and call it a day. The other three are where dental practices actually live or die. This is the field guide to all four.
MatrixPer-vertical deep reads
Sixteen articles. One per layer × category.
Each layer reads differently for each kind of clinic. What makes a good pediatric booking flow is not what makes a good cosmetic booking flow— and both are substantive enough to warrant their own deep read. We're writing them one at a time. Available cells link to the article; the rest say "Coming soon" honestly.
Marketing site
The site visitors actually see.
family-practice marketing site
SoonEditorial design that lets the practice's personality come through, locale-specific content, and 30-second updates from the front desk.
pediatric marketing site
SoonParent-first voice without baby-talking the parent. Specific accommodations and credentials that build trust before the booking.
cosmetic marketing site
Real before-and-afters with verifiable consent, transparent package pricing, and voice that respects educated patients.
orthodontic marketing site
SoonTwo-audience copy (parents for teens, adults for themselves), duration-honest timelines, and treatment options without hype.
Booking
The HIPAA-aligned entry point.
family-practice booking flow
SoonMinimum-necessary intake, encrypted PHI columns, PHI-free email notifications, and operator-side reveal-on-click with audit.
pediatric booking flow
Parent-first by data model and by copy, age-routed sections, COPPA-aligned, schema-enforced parent-or-guardian capture.
cosmetic booking flow
SoonConsultation-first scheduling, package pre-selection, financing pre-qualification — without chasing patients off-platform mid-flow.
orthodontic booking flow
SoonVirtual consult intake with encrypted photo upload, parent / adult branching, no auto-generated treatment estimates.
Admin
What the front desk uses.
family-practice admin
SoonEight task tiles, each a 30-second form. The front desk updates hours and approves reviews without a developer ticket.
pediatric admin
SoonParent-first labels through the review queue, special-needs flags surfaced where the chair-side staff can see them.
cosmetic admin
SoonGallery editor with consent capture inline, package editor with starting-at vs consultation-required modeling, financing partner management.
orthodontic admin
Virtual consult review queue with masked-by-default PHI + audit-on-reveal, status flow that honors the year-plus relationship.
Database
Where every layer eventually lives.
family-practice database
Tenant isolation at the database (FORCE RLS + per-transaction GUC), AES-256-GCM PHI columns, audit log keyed off the same encryption.
pediatric database
SoonParent_or_guardian as a distinct encrypted column, child_age as a plain integer (Safe Harbor), age-routed intake submissions.
cosmetic database
SoonConsent_records lattice with revocation cascade, transformation_gallery with one-consent-per-pair invariant, package modeling that supports both pricing philosophies.
orthodontic database
SoonVirtual_consults with encrypted multi-photo storage, age-aware patient/requestor split, status lifecycle that audit-emits every transition.
Layer 01The marketing site
The site visitors actually see.
The public-facing homepage. It's the first thing a prospective patient sees, the first thing Google sees, and the first thing a competitor's clinic compares yours to. It's also the layer most clinics treat as the only layer — paying for a pretty page and not thinking about what's behind it.
The wrong way
- Stock photography of teeth that doesn't match the actual practice.
- Generic copy that could belong to any clinic in any state.
- Slow load times because of carousel sliders and 4MB images.
- No real local-SEO presence — the clinic is invisible to its own neighborhood.
- Forgotten by the marketing agency the day it was published.
The Dream Create way
- Clean editorial design that lets the practice's own personality come through.
- Locale-specific content — city pages, neighborhood references, real photos of real staff.
- Performance-budgeted from the database up: every image optimized, every font subset.
- Updates that take 30 seconds from the front desk, not 30 days from a developer.
- Maintained by the platform itself — every clinic upgraded together when the platform improves.
“A marketing site is not a brochure. It's the first half of a conversation with a future patient — and that conversation needs to keep working long after launch.”
Layer 02The booking flow
Where a patient turns into an appointment.
Booking is where most clinic websites quietly betray HIPAA. A scheduling widget bolted onto a marketing page, talking to a third-party calendar that may or may not have a BAA, with intake forms that may or may not encrypt PHI. The patient sees a clean booking screen; behind it, their data is in a pipeline nobody documented.
The wrong way
- An iframed booking widget from a vendor with no BAA.
- Intake forms that POST to a Google Sheet or unsecured database.
- PHI sitting in plaintext in marketing analytics.
- Friction-heavy flows: 18 fields before the patient picks a date.
- Email confirmations that include identifying details in cleartext.
The Dream Create way
- Booking and intake live on the same HIPAA-aligned database as the rest of the platform.
- BAA included by default — every clinic on the platform is covered.
- Minimum-necessary fields: name, contact, reason. Anything else lives in the encrypted intake portal.
- Audit-logged at the row level so a compliance review can answer 'who saw what'.
- Confirmation emails template-driven, no PHI in the body, just 'your appointment is confirmed'.
“A booking flow that's pleasant for the patient and compliant for the clinic isn't a trade-off. It's the same architecture done well.”
Layer 03The admin dashboard
Where the front desk runs the website.
The CMS. The piece nobody sees from the outside, and the piece that determines whether the website stays alive after launch. Most clinic sites die here — handed to a front-desk team that opens WordPress once, can't figure out how to change Wednesday hours, and never logs in again. The site rots from the back, and the public face follows.
The wrong way
- WordPress with eight plugins that conflict with each other.
- A 'page builder' that requires understanding columns, rows, and z-index.
- Updates that need a developer ticket and a 2-week turnaround.
- No publishing preview — you change something and pray.
- A login screen that staff lose access to within six months of launch.
The Dream Create way
- Form-based editing of the things clinics actually change: hours, services, team, photos, reviews.
- Schema-driven, not blank-canvas: the platform handles layout; staff fill in fields.
- Live preview before publishing — see exactly what will go live.
- Single sign-on tied to clinic staff identity, not a generic 'admin' account.
- Audit trail on every change: who edited the hours, when, and what they were before.
“The CMS is the part of a website that determines whether the website is alive in 18 months. A great public face on top of a brittle admin is just a delayed failure.”
Layer 04The HIPAA-aligned database
Where every other layer either lives or leaks.
The deepest layer, and the one most clinics never see. Every booking, every intake form, every patient name and phone number ends up here. If this layer isn't HIPAA-aligned — encrypted at rest, audit-logged, access-controlled, BAA-covered — none of the other three layers matter. A pretty homepage on top of an unencrypted database is a breach waiting to be reported.
The wrong way
- PHI stored in marketing-site databases not designed for medical data.
- No encryption at rest — patient data sitting in plaintext on a managed Postgres.
- Shared credentials, no access-control by role.
- No audit logs, so a compliance review can't reconstruct who saw what.
- No BAA with the database vendor, leaving the covered entity carrying all of the risk.
The Dream Create way
- AES-256 at rest, TLS in transit, every PHI column individually encrypted.
- Tenant isolation enforced at the database layer (RLS), not at the application layer.
- Audit trail on every read and write of identifying data, retained per HIPAA timelines.
- BAA included as a platform default — covered entities don't have to negotiate anything.
- Schema designed for minimum-necessary: you can't accidentally store PHI you didn't intend to.
“HIPAA compliance isn't a feature on a checklist. It's a posture that has to start at the database layer and earn its way up to the public site. Anything else is theater.”
ClosingThe layers, together
One platform, every layer, all four built once.
Most clinics buy a website from a marketing agency that knows Layer 01, and Layers 02–04 are someone else's problem. Dream Create is the opposite shape: every clinic on the platform inherits all four layers built and maintained together. One upgrade improves every site. One BAA covers every clinic. One audit trail spans every layer.