Stomagia
A client-operable clinic website, from initial brief to production
Stomagia is a live dental-clinic website built with WordPress as the content and API layer and Next.js as the public frontend.
I owned the documented project scope end to end: information architecture, content and copy, UX/UI, WordPress/PHP and Next.js implementation, integrations, deployment, and production validation. The clinic owner reviewed the medical wording for accuracy before publication.
The delivered system lets authorized clinic staff manage content, publish urgent operational information immediately, review structural changes on Preview, run relevant checks, and promote the approved frontend to Production without requiring GitHub access.
From an initial brief to a complete product
The clinic owner provided an initial service list and medical context. I turned that brief into the information architecture, copy, interface, technical solution, and review-ready content.
Services, team and business information, FAQs, and contact details needed to remain manageable after launch. Google reviews had to reach the frontend without manual CMS duplication, while contact and appointment actions stayed accessible across mobile and desktop.
The system I built
WordPress is the CMS and backend API; a separately deployed Next.js application owns the public experience. A custom headless theme defines CMS behavior and protects the intended REST surface.
The CMS/theme, static frontend, reviews API, Playwright framework, GitHub Actions, and Deploy & Test control surface form one delivery system.
Trustindex synchronizes Google reviews, which a small custom API exposes to Next.js instead of duplicating them in the CMS.
- Services
- Team
- General Info
- SEO
- REST APIs
- Static site build
- Manual review
- Automated checks
Configured actions stay accessible in WordPress while GitHub runs the underlying workflows.
Separately maintained parts of the same delivery system.
Two proportionate publishing paths
Structural changes follow a reviewable release; urgent operational information can become public immediately.
Reviewed structural changes
- Edit content in WordPress.
- Deploy the generated frontend to Preview.
- Review it on
preview.stomagia.ro. - Run the relevant automated checks.
- Inspect status and evidence in WordPress.
- Promote the accepted artifact to Production.
Immediate operational updates
Opening hours and temporary announcements update directly from WordPress without a frontend build or deployment.
From content edit to Production
A representative change passes through a visible Preview, review, and validation path before it reaches the live frontend.
- 01
Edit in WordPress
Clinic content is edited in the CMS, including structured service fields and supporting FAQs.
- 02
Build the Preview
An authorized editor starts the Preview workflow from Deploy & Test and can follow its status without leaving WordPress.
- 03
Review the result
The resulting page is checked as a real visitor would see it before the change is accepted for Production.
- 04
Validate and publish
Test evidence is returned to WordPress, and the accepted frontend can then be promoted to Production.
No frontend deployment required
Time-sensitive operational information follows a direct path from WordPress to the live frontend.
Opening hours
Authorized staff can change the schedule in WordPress and see it reflected immediately in the public navigation.
Temporary announcements
A short message can be enabled from the same screen and appears as a prominent banner on the live website.
Product and release decisions
The operating model protects reviewed output, keeps routine updates accessible, and holds future content until approval.
Promote the reviewed output
Production reuses the successful Preview artifact, so the reviewed version becomes public without a rebuild.
Combine judgment with automation
Manual review covers content and presentation; automation covers repeatable behavior such as navigation, contact destinations, API contracts, metadata, and page generation.
Keep GitHub out of the clinic workflow
Configured actions, status, test summaries, and audit history are available in WordPress, so authorized clinic staff can operate the website without repository access.
Keep future content private by default
The frontend does not request or expose Clinical Cases while the feature is disabled pending approved content and written patient consent.
Built and validated, but intentionally not public
Clinical Cases is implemented across WordPress and Next.js, including structured content, listings, individual pages, and before-and-after comparisons. It was validated with clearly labelled synthetic content but remains unavailable publicly pending approved material and written patient consent.
- Implemented
- Validated with synthetic content
- Public rollout pending approval and consent
Designing for patient journeys
The responsive experience begins with what a visitor needs to accomplish.
- Understand the clinic and its principal services.
- Move from a service listing to the correct detail page.
- Use the intended phone, WhatsApp, contact, or appointment action.
- Find current clinic information on mobile.
- Navigate comfortably on mobile without hidden or unreachable controls.
- Continue using the core website when optional external content is unavailable.
Critical CMS data can stop a build that would produce incomplete essential pages; optional integrations such as reviews can degrade without taking down the website.
Validation and production checks
Checks run at the smallest reliable layer rather than through one large end-to-end suite.
Frontend checks
Linting, type safety, focused unit behavior, and static generation.
PHP checks
Theme syntax and public REST-allowlist regression coverage.
API checks
CMS settings, services, reviews, response contracts, and feature flags.
Playwright UI
Navigation, responsive behavior, search, contact destinations, and public journeys.
SEO checks
Canonicals, metadata, JSON-LD, robots rules, and sitemap content.
Navigation smoke
Page loads and significant first-party request failures.
Lighthouse
Repeated mobile performance, accessibility, and SEO measurements using median results.
Post-deploy smoke
WordPress operation after a theme upload.
Allowlisted third-party image failures become warnings; unexpected application and first-party failures remain blocking.
28 / 28 checks passed
Lighthouse checks passed
Outcome
Stomagia is a live, actively maintained client website that clinic staff can operate without direct GitHub access.
The project moved from a small brief to a complete content, interface, and technical system spanning requirements, UX/UI, WordPress/PHP and Next.js implementation, CMS–frontend and reviews integrations, deployment, validation, and ongoing operation.