Stagg Support

The starting brief was direct: "I want blue and don't be afraid of colour."

Design came first. Three concepts were developed - ranging from multi-shade blue palettes to bold accent-bar layouts - giving the client a genuine choice of direction. The chosen concept uses a single vivid teal as its primary accent: strong enough to feel distinctive, restrained enough to keep the content in front.

With direction agreed, the build followed a clear separation of concerns. PHP handles templating and server-side logic; MySQL stores content; a single CSS file built on custom properties keeps the design system consistent and easy to maintain; a minimal vanilla JS module handles the mobile navigation.

Content architecture was agreed before a line of PHP was written. Rather than building static pages and retrofitting a CMS later, the database structure - pages, content blocks, testimonials, stats, feature cards - was designed first. The public site and the admin panel were built in parallel, every editable field wired from the outset rather than bolted on at the end.

Accessibility was designed in, not audited in. The site needed to work for people who rely on assistive technology, and addressing that from the start costs significantly less than retrofitting it later.

The skip link is the first element in the DOM on every page - placed in the shared header include so it can never be accidentally omitted when a new page is added. Every `<main>` carries a matching `id="main-content"` target. Focus styles use `:focus-visible` throughout rather than suppressing outlines globally - keyboard users get intentional indicators; mouse users aren't distracted by them. The mobile navigation tracks its own state for assistive technology on every interaction: `aria-expanded` and `aria-controls` toggle on every open and close, and ESC dismisses the menu from anywhere on the page. The specific quirk of Safari with VoiceOver - which strips list semantics from CSS-restyled `<ul>` elements - was addressed with `role="list"` across the site.

Every one of these decisions, taken at the right stage of the project, meant nothing needed to be unpicked later. The design, the content architecture, and the accessibility layer all fit together rather than fighting each other.

Most care provider websites do one of two things: say too little - a phone number and a tagline - or say too much without organising any of it. Dan's requirement was transparency: enough for a potential client or family member to understand exactly what Stagg Support offers and what they can expect from it. Getting that balance right meant some pages went through more structural rethinking than others.

The contact page layout

The contact page went through more iterations than anywhere else on the site.

The original structure was straightforward: heading, then form. The problem was that it put the full weight of a form in front of visitors who might only want a phone number or email address. The solution was to restructure the page into four distinct zones - a hero with introductory copy, a contact cards strip for direct contact details, the form itself, and a full-width map at the foot. Each zone serves a different intent: the cards intercept people who don't need the form; the form is there for those who do. Alternating background tints give each section its own visual space without hard divisions.

The form had its own layout challenge: email and phone sit side-by-side in a two-column grid, and neither field is individually required - but at least one must be provided. That interdependency is straightforward in PHP, but the client-side validation had to mirror the same logic and surface the error clearly against the right fields without confusing the user.

Validation runs PHP-primary: the server-side handler is the source of truth, and the JavaScript layer mirrors its rules exactly to catch errors before the round-trip. The submit button disables and relabels to "Sending…" once the JS layer passes, preventing double submissions while giving clear feedback. The CTA section present on every other page was deliberately removed from contact - elsewhere it links to this page, and including it here would loop back to itself.

Building a CMS without a framework

The admin panel needed to be secure, usable, and maintainable - but the project's existing architecture pointed away from pulling in Laravel, and WordPress would have been the wrong tool for a site with this level of custom structure. The authentication system was built from scratch: PHP sessions, bcrypt password hashing, and a remember-me implementation using selector/validator token pairs stored hashed in the database, expiring after 30 days, invalidated on logout. The content system was built field-by-field, with a type-aware block structure that distinguishes plain text, multi-line text, and HTML fields per page section.