Serene Family Dental came to us with an ASP.NET template site that still had fake New York addresses and placeholder doctor names on the cosmetics pages. PageSpeed: 45. The site was embarrassing to share. Two weeks later, it scored 91 on PageSpeed, 100 on Accessibility, 100 on Best Practices, and the booking form was above the fold on every page.
This is the story of how we rebuilt the Serene Family Dental website — and every decision that mattered.
What we were working with
The old site was an ASP.NET template purchased years ago and bolted onto a Windows server. It looked like a dental website at first glance. Look closer and the cracks were everywhere.
- Fake content throughout. The cosmetics pages still listed "Dr. Clara Lee" — a placeholder name from the template. The address showed a New York location. The phone number was American. None of this belonged to the actual practice in Ropes Crossing, NSW.
- PageSpeed: 45/100 on mobile. Bloated scripts, unoptimised images, render-blocking resources. More than half of mobile visitors were likely bouncing before the page finished loading.
- No SEO foundations. No meta descriptions on any page. No schema markup. No structured data. Google had very little to work with.
- Database-driven on a Windows server. The client couldn't update a single word without calling a developer. Changing the opening hours meant raising a ticket and waiting.
- Accessibility: 81/100. Best Practices: 73/100. Not terrible, but well short of where a healthcare website should be.
The practice had been putting up with it because rebuilding felt like a big, expensive project. It didn't need to be. We scoped the entire rebuild at two weeks.
The decisions that shaped the build
Every project has a handful of decisions that define the outcome. These are the six that mattered most for Serene — and why I made each one.
Decision 1: Hand-code, don't use WordPress
The old site's problem was bloat. An ASP.NET template loaded scripts the practice didn't need, images that weren't optimised, and database queries for content that never changed. WordPress would solve some of those problems while introducing different ones — plugin bloat, security patching, hosting costs, and a dependency on PHP that adds latency to every page load.
Hand-coded HTML means writing only the code the page actually needs. No jQuery library loaded for a single animation. No page builder adding wrapper divs. Every line of CSS does something visible. The result: a page that loads in under 1 second on mobile. You can test it yourself at pagespeed.web.dev.
Decision 2: Mobile-first, not mobile-responsive
There's a difference between "works on mobile" and "built for mobile." Most agency sites are designed on a desktop monitor and then squeezed to fit a phone screen. We did the opposite. I designed the mobile view first — the layout, the tap targets, the content hierarchy — and then scaled up to desktop.
Ropes Crossing is a young, family-focused suburb in Western Sydney. Most patients search for a dentist on their phones, usually while sorting out something else at the same time. The mobile experience had to be fast, clear, and direct. Click-to-call is above the fold on every page. The booking widget loads without scrolling. If you're on a phone and you need a dentist, you can book in under 10 seconds.
Decision 3: Embed HotDoc booking, don't just link to it
Most dental websites handle online booking by linking to HotDoc or HealthEngine. The patient clicks a button, leaves the website, lands on a third-party platform, and books from there. Every extra click is a dropout point. Every redirect is a chance for someone to get distracted, close the tab, or decide to call another practice instead.
We embedded the HotDoc booking widget directly into the Serene site. The patient stays on the page. They see available appointment times without leaving. One fewer click, one fewer dropout point. For a practice that relies on online bookings, this is the kind of detail that adds up over hundreds of visitors per month.
Decision 4: AHPRA compliance baked in from day one
Dental websites in Australia must comply with AHPRA advertising guidelines. The rules are specific: no guaranteed outcome claims, no unverified testimonials, no before-and-after photos without documented patient consent and appropriate context. Many dental websites — especially template-based ones — violate these rules without the practice even realising it.
I reviewed every page against AHPRA's guidelines before launch. Service descriptions explain what each treatment involves without making promises about results. Testimonials reference the experience of visiting the practice, not clinical outcomes. This isn't optional — it's a legal requirement — and it's something most web designers don't think about because they don't build for healthcare.
Decision 5: Zero-downtime migration
Serene had existing patients who knew the old URL. They had Google Business Profile links pointing to specific pages. They had directory listings across the web. A botched migration — even for a few hours — means broken links, lost rankings, and patients hitting 404 pages when they're trying to book an appointment.
We planned the DNS transition so the old site stayed live until the new one was fully tested and ready to serve traffic. The switch was instant. No downtime, no 404s, no ranking drop. Every old URL either mapped to its equivalent on the new site or redirected properly. This is one of those things that nobody notices when it goes right — but everyone notices when it goes wrong.
Decision 6: Give the client full ownership
The old site was locked in a Windows server they couldn't touch. Want to update your hours? Call the developer. Want to add a new dentist? Raise a ticket. Want to move to a different provider? Good luck extracting your content from an ASP.NET database.
The new site is static HTML hosted on Cloudflare Pages. The code lives in a GitHub repository that Serene owns. They can update content through PagesCMS — a free, open-source CMS that connects to GitHub — without calling anyone. If they stop working with us tomorrow, the site stays live. There's no hosting fee to cancel, no platform subscription to lapse, no vendor lock-in. They own everything.
This is a deliberate philosophy. I don't want clients staying because they're locked in. I want them staying because the work is good.
The numbers
Here's the before-and-after, measured by Google PageSpeed Insights on mobile.
| Metric | Before (ASP.NET) | After (Hand-Coded) | Change |
|---|---|---|---|
| Performance | 45 | 91 | +46 points |
| Accessibility | 81 | 100 | +19 points |
| Best Practices | 73 | 100 | +27 points |
| Timeline | — | 2 weeks | Brief to live |
| Ongoing fees | Server + developer | $0 | No CMS or platform fee |
| Package | — | Scale ($4,000) | Founding rate |
| Google Reviews | — | 27 reviews, 5.0 stars | Since launch |
The Performance score jumped 46 points. Accessibility and Best Practices both hit perfect 100s. The site went from a liability to something the practice actively shares with patients. And the ongoing cost to keep it running is zero — no CMS subscription, no platform fee, no managed hosting bill.
What I'd do differently
If I rebuilt Serene's site today, I'd push harder on getting analytics properly configured before launch day. We had Google Analytics set up, but the event tracking — form submissions, click-to-call taps, HotDoc widget interactions — came together in the week after launch rather than being ready from day one. That meant we lost a week of conversion data.
In the scheme of things, a week of missed data isn't a disaster. But when you're trying to show a client the impact of a rebuild, having complete data from the moment the site goes live makes the story cleaner. I've since added analytics configuration to the pre-launch checklist. Every site now has event tracking tested and confirmed before DNS switches over.
I'd also have built the blog section with more posts ready at launch. We launched with the core service pages and the homepage, which was the right call for speed — but having two or three blog posts live from day one would have given Google more content to index and started building topical authority earlier. We're building that out now through the dental content strategy.
What the client said
"We had been putting up with our old website for too long — it was embarrassing to hand out the URL. Webstallion turned it around in two weeks and the new site actually looks like a proper dental clinic. Patients have commented on it. The booking process is smoother, it loads fast, and we can finally update our own content without calling a developer."
Common questions
How long did the Serene Family Dental website take to build? +
Two weeks from brief to live site. That includes initial design concepts, all page builds, content writing, HotDoc integration, AHPRA compliance review, and DNS migration.
What was the old site built on? +
ASP.NET template with a Windows server backend. The site still had placeholder content from the template — fake doctor names, a New York address, and US phone numbers on several pages.
What PageSpeed score does the new site get? +
91 on mobile Performance, 100 on Accessibility, and 100 on Best Practices. The old site scored 45 on Performance, 81 on Accessibility, and 73 on Best Practices.
How much did the rebuild cost? +
Scale package at the founding rate ($4,000). See our services page for current pricing.
Can the client update the site themselves? +
Yes — via PagesCMS, a free CMS connected to GitHub. The client can update text, images, and page content without calling a developer or paying for a CMS subscription.
Can you do this for my dental practice? +
Yes. Every dental site we build includes HotDoc or HealthEngine integration, AHPRA-compliant copy, click-to-call, and the 90+ PageSpeed guarantee. Book a free 30-minute call to discuss your practice.