Transparent Build Case Study

How We Rebuilt Smile AI Marketing's Own Platform

Subject: Smile AI Marketing's own platform • Published 2026-08-04

Before we ask a dental practice to trust our audits, we applied the same standard to our own platform: less text, clearer structure, and forms and navigation that actually hold up on mobile. This case study covers what changed and how each claim was verified — no patient or revenue figures, because this is our own build, not a client outcome.

The problem

The platform's landing page had grown to 11 overlapping content blocks with duplicated calls to action. The audit intake flow mixed a loading state and a contact-detail gate into a single ambiguous step. The admin dashboard was built around a permanent sidebar with no overview page — there was nowhere to land and see what needed attention. Forms across the app mixed two incompatible design-token systems, and a number of interactive controls fell below a comfortable mobile touch-target size.

Before & after

MetricBeforeAfter

Landing page content blocks117

Primary CTA label variants in use4 ("Analyse My Practice", "Run This Audit for My Clinic", "Get Your Free Growth Plan", "Get Free Consultation")1 ("Audit My Practice")

Admin navigationPermanent sidebar, no overview/landing pageTop nav (desktop) + bottom nav (mobile) command-centre, with a 6-card work-queue Overview page

Shared form primitives in use06, applied to every form in the app

Interactive controls below a 44px touch targetPresent (e.g. 36–40px buttons)0 — standardized to ≥44px

Pre-existing ESLint problems46 (37 errors, 9 warnings)4 errors, 2 warnings — all confirmed pre-existing, zero new introduced

What we did

Landing page

Reduced to 7 sections (hero, sample audit, key problems, process, trust & consultation, FAQ, final CTA) and consolidated every call to action to one consistent label.

Audit intake flow

Rebuilt as an explicit 4-step wizard — practice details, processing, preview, contact — with a visible progress indicator, replacing a 2-step flow that conflated loading and contact-gating.

Admin dashboard

Removed the permanent sidebar. Replaced it with a top/bottom-nav command-centre and a new Overview page surfacing real work queues (audits ready for review, hot leads, follow-ups due, meetings, recent activity).

Forms & accessibility

Introduced shared Button/Input/Textarea/Select/FormField/ProgressSteps primitives, standardized every touch target to at least 44px, and migrated legacy design tokens onto one semantic system.

Code health

Resolved the large majority of pre-existing ESLint errors as a byproduct of the rewrite, with zero new errors introduced, and verified a clean production build after each phase of work.

Evidence

This repository's own commit history (commit c069479, 45 files changed, +2595/-2091 lines)
Direct ESLint output comparison against a git-stashed pre-redesign baseline
A manual responsive-class code audit across 320–430px breakpoints
Production build output (next build) confirming zero new errors across two build phases

Limitations & context

This is an internal engineering case study describing our own platform — not a client outcome. It does not include patient-enquiry, booking, or revenue figures, because analytics tracking was not yet implemented at the time of this build. It should not be read as a guarantee of results for any dental practice client; real client outcomes depend on that practice's own market, competition, and starting position.

Next steps

Wire the analytics event pipeline so the redesigned funnel can be measured directly, extend the same design system to any remaining legacy-styled pages, and publish verified client case studies once real campaigns and audits are running on real data.

Curious what an audit finds for your practice?

Audit My Practice