New-patient website and booking path
A practice site rebuilt around the single question a prospective patient is actually asking (can I be seen, and how soon) with a booking path short enough to finish on a phone in a waiting room.
- Status
- In build
- Year
- 2026
- Services
- A site that does not sell
- Published results
- None yet
Named on request. The practice has not yet approved public attribution, so it is described rather than named here.
The problem
A prospective patient arriving on a practice website is doing one thing: deciding whether they can be seen, soon, by someone who seems competent. The existing path made them find that out by reading a service list first, and the booking step was the last thing on the page rather than the point of it.
How it worked before
- The homepage opened with a list of every service offered
- Booking was a form near the bottom, below the fold on every phone
- The site was assembled from a template, so page speed was whatever the template did
- New-patient questions (availability, insurance, what happens first) were spread across four pages
What was in scope.
Deliverables, not outcomes. Anything not on this list was not built, and is not implied to have been.
- Conversion-focused website, built from scratch
- An original animated hero rendered in the browser, not licensed stock footage
- Inquiry and booking path, mobile first
- A performance budget enforced on mid-range phones
- Accessibility and reduced-motion handling throughout
The system, stage by stage.
Each stage does one thing and hands off. The marked stages are the ones a person owns: they are in the diagram because they are part of the design, not because nothing else could reach them.
Visitor arrives
Usually on a phone, usually from a map or a search result, usually with one question.
The question answered first
Availability and the path to book are the opening of the page, not the end of it.
Capability-gated hero
The animated opening is fetched only by hardware that can run it; everything else gets a static first frame.
Booking path
Short enough to finish standing up, with the objections answered inline rather than on another page.
Inquiry reaches the practice
Routed to where the front desk actually looks, with the details already collected.
The practice responds
Human decisionA person books the appointment. Nothing on this site talks to a patient about their teeth.
One stage in this system is owned by a person. It stops there deliberately: those are the points where being wrong is expensive.
Runs on
Tools you can keep without us.
Everything is set up on your own accounts and your own billing, so the system does not stop working if we do.
- Next.js & ReactWhat the websites are built in, including this one. Code rather than a page builder, which is what makes a performance budget enforceable.
- VercelHosting and edge delivery for the sites we build. The account is the client's.
- Privacy-respecting analyticsEnough measurement to know whether a page works, without a tracking stack that costs the visitor a second of load time.
These are tools we build with. Braav Labs is not affiliated with, endorsed by or a partner of any of them, and all names belong to their owners.
Why it was built this way.
- 01
The page had to answer one question, not five
Most practice websites open with a list of every service offered. A prospective patient is rarely shopping a menu. They have one problem and one calendar. The page leads with availability and the path to book, and moves the service list to where somebody who wants it will look for it.
- 02
The hero is built, not bought
The opening animation is rendered live in the browser rather than being a stock video loop. That was a deliberate cost: it meant writing a real rendering pipeline, and then writing a governor that measures its own frame times and sheds work when a device cannot keep up. A phone that cannot run it never downloads it. The heavy code is fetched only on hardware that will use it.
- 03
Nothing on the page gives clinical advice
Every line is about scheduling, access and communication. Patient-facing wording is written for the practice to approve before it goes live, and the site does not diagnose, triage, or advise. That boundary is a design constraint, not a disclaimer added at the end.
Results
No measured result yet.
This build has not run long enough to produce a number we can stand behind and show you the source of. When it has, the figure and where it came from go here. We would rather this section say nothing than say something we cannot evidence.
On visual evidence
No screenshots are shown. Every screen carries the practice's branding, and they have not yet approved being named publicly. Publishing the images would identify them regardless of the wording. They go up if and when that approval is given in writing.
What we would change
What we would do differently.
Written down because the next client gets the version of us that already made these mistakes.
The performance governor should have been written before the animation, not after. Building the effect first meant a week of cutting it back to fit a budget that could have shaped it from the start.
Content approval is the long pole in a regulated setting, and scheduling it as a final review rather than a parallel track is what moved the date.
Asking for attribution rights at the proposal stage, rather than near launch, would have meant this case study could carry the practice's name and its screenshots.
Want something like this built for your business?
Get my free auditOther work
- Our own sourcing and follow-up pipelineThe system we use to find practices that fit what we do, screen them, and make first contact, running against our own inbox before it is ever sold to anyone else.
- Voice agents that play a hard prospectTwo voice agents, a receptionist and an owner, chained into one call so a sales pitch can be rehearsed against a real gatekeeper before it is spent on a real lead.
- Social posts written from cited researchThe system that drafts, renders and queues our own social posts every morning. Every claim comes from a fixed library of cited sources, and nothing posts until a person approves it.
How an engagement runs.
The same five steps whatever we are building, so you always know which one you are in.
- Pricing
- Fixed price, quoted after a scope call
- You have the number before anything is built. Nothing is billed by the hour.
- Timeline
- A date at quote time
- Stated as a commitment, not an estimate that drifts once work starts.
- Ownership
- Everything stays in your name
- Domains, hosting, inboxes and every account, on your billing, documented.
- 01
Scope call
Twenty minutes on how inquiries reach you today. No deck, no discovery package.
- 02
Written scope and a fixed quote
What gets built, when it lands, what it costs. Fixed before anything starts.
- 03
Build and review
You see it working on your own content, not a screenshot of it working.
- 04
Launch and handover
Accounts in your name, a written record of what runs where, a walkthrough.
- 05
Support, if you want it
A separate decision, made after something is already running.
