Building a specialist website without rewriting the specialist.

When the design and the words have already been approved, the developer's job becomes very specific: make them work on the web without quietly changing what was agreed.

That was a central constraint in my Dizzyology build. The project arrived with approved visual designs and a supplied copy deck. The design credit belongs to Designable Studio. My part was the website implementation through Wicked Web Design.

Dizzyology is a specialist vestibular assessment clinic. This article is about building its website, not advice about dizziness or a claim about patient outcomes.

The site went live on 1 September 2026. The handover, including the CMS manual, was completed on 7 September.

Start with what is already decided

The project instructions were unusually clear. Keep the supplied copy verbatim. Follow the approved design PDFs. Use the established brand colours and typography. Flag missing material rather than inventing filler.

Those constraints are valuable on a specialist project. A sentence that looks long to a developer may carry a distinction the client needs. A layout that seems easy to simplify may have already been agreed with the designer.

The implementation needs to make those decisions usable at different screen sizes. It does not automatically have permission to rewrite them.

That also matters when AI tools are involved. A suggestion to shorten a paragraph or restyle a section can sound helpful while moving the build away from its actual brief. The approved material needs to remain the reference against which changes are checked.

A desktop design is the beginning of the responsive work

A design PDF is a fixed view. A website has to accommodate narrow phones, larger screens, longer headings and different ways of navigating.

The Dizzyology project rules made small-screen checks explicit, including 320 and 375 pixels. They called for space between content and screen edges, touch targets that can be used comfortably, and checks for horizontal overflow.

Those are concrete things a reviewer can inspect. "Mobile-friendly" on its own tells you very little about what was tested.

The build record also preserves a useful warning: a global CSS fix had caused a wider mobile regression. A rule that helps one page can change other pages using the same layout. The response was to require checks across page types when shared styling changed.

For an owner commissioning a site, ask to see several real pages on a narrow screen, especially the ones with long headings or complicated sections. A homepage alone cannot stand in for every layout.

Keep the information in the page

The implementation uses Astro. The project's progressive-enhancement rule requires the content to be present in rendered HTML, with JavaScript enhancing the experience rather than being the only way to reach the information.

The idea is straightforward: the basic page should still be useful before optional interactive behaviour is added.

This does not make a website automatically accessible or remove the need for testing. Keyboard behaviour, contrast, focus states and responsive layouts still need attention. The project instructions even identify a contrast conflict in the approved design and require it to be flagged rather than silently changed.

That is a real trade-off in implementation: respecting an approved design and identifying a problem in it are both part of the job. Neither should be hidden behind a broad claim that everything has passed.

The handover is another interface

There is the website a visitor uses, and there is the system the owner has to use afterwards.

The source includes a Git-backed CMS, and the handover included a CMS manual. A Git-backed approach stores content changes in the project's version history. It still requires a clear editing and publishing process, appropriate access and somebody who knows what to do when a change needs help.

That is why the handover deserves its own attention. A live website and an owner who can confidently maintain it are related outcomes, but they are not the same check.

I am keeping the result here to what the record supports: the site launched and the handover was completed. There is no measured increase in bookings or evidence of improved patient understanding to report in this article.

What I would ask before a specialist build

Three questions make the work easier to define:

• Who owns the design and wording, and what may the builder change?
• Which page types and screen sizes will be shown during review?
• How will the owner edit, review and publish content after handover?

The Dizzyology project gives those questions a concrete setting. The work was to carry approved material into a functioning website, keep the constraints visible and make the result maintainable.