Stomagia
A client-managed clinic website with controlled publishing and QA
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 project end to end, from content strategy, copywriting, and UX/UI design through architecture, development, infrastructure setup, deployment, and Quality Engineering.
The completed system lets authorized clinic staff manage content, review structural changes on Preview, run relevant automated checks, and publish the approved frontend to Production without requiring GitHub access.
From an initial brief to a complete product
The clinic owner provided an initial list of services and the necessary medical context. From that starting point, I defined the information architecture, developed and refined the copy, designed the interface, implemented the complete technical solution, and prepared the content for review. The owner checked the final wording for medical accuracy and approved it before publication.
Services, team and business information, FAQs, and contact details needed to remain manageable after launch. Google reviews also needed to reach the frontend without being copied manually into the CMS. The public experience had to explain services clearly across mobile and desktop while keeping contact and appointment actions easy to reach.
The system I built
WordPress is the single CMS and backend API, while a separately deployed Next.js application owns the public experience. A custom headless theme defines CMS behavior and protects the intended public REST surface.
The independently maintained repositories form one delivery system: the CMS and theme, static frontend, reviews API, Playwright framework, GitHub Actions, and Deploy & Test as the WordPress control surface.
Google reviews are synchronized through Trustindex and exposed to Next.js through a small custom API rather than being authored manually 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 receive a reviewable release, while 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 announcement banners can be updated directly from WordPress and appear on the live website immediately.
These operational updates do not require a frontend build or deployment.
This supports holiday schedules, unexpected closures, and other time-sensitive clinic information.
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.
Designing around release risk
The publishing model protects what is reviewed, keeps operations accessible, and prevents future content from becoming public before approval.
Promote the reviewed output
Production reuses the exact successful Preview artifact instead of rebuilding the frontend. The version reviewed before release is the version that becomes public.
Combine judgment with automation
Manual review protects content, layout, and visual context. Automation protects 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
Clinical Cases remains unavailable on the public website until approved content and written patient consent are available. The frontend does not request or expose that content while the feature is off.
Built and validated, but intentionally not public
Clinical Cases is implemented across WordPress and the Next.js frontend, including structured content management, listings, individual case pages, and before-and-after comparisons. The feature was validated with clearly labeled synthetic demo content, but remains unavailable on the public website until the clinic provides approved material and written patient consent.
- Implemented
- Validated with synthetic content
- Public rollout pending approval and consent
Protecting patient-facing journeys
Coverage begins with what a visitor needs to accomplish, not with isolated interface components.
- 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 frontend build when it would otherwise produce incomplete essential pages. Optional integrations such as reviews can degrade without taking down the complete website.
Risk-based Quality Engineering
Each risk is assigned to the smallest reliable layer instead of forcing every check through a large end-to-end suite.
Frontend checks
Linting, type safety, focused unit behavior, and static generation.
PHP checks
Theme syntax and regression coverage for the public REST allowlist.
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, parsed JSON-LD, robots rules, and sitemap content.
Navigation smoke
Page-load success and significant first-party request failures.
Lighthouse
Repeated mobile performance, accessibility, and SEO measurements using median results.
Post-deploy smoke
Confirmation that WordPress remains operational after a theme upload.
Third-party image failures become warnings only when they match an explicit allowlist. Unexpected application and first-party failures remain blocking.
28 / 28 checks passed
Lighthouse checks passed
Outcome
Stomagia is a live and actively maintained website supported by an end-to-end delivery and operating model rather than a collection of static pages. Authorized clinic staff can manage content, publish urgent information immediately, review structural changes on Preview, run relevant checks, and promote the approved frontend without direct GitHub access.
The project demonstrates ownership across product delivery and Quality Engineering: transforming a small initial brief into a complete content and visual system, defining the CMS–frontend boundary, protecting patient-facing journeys, and making release validation repeatable.