← ALL WORK
W-06
Case study
Case study
production·shipped 2026-06·LH 83 mobile
Apex Workspace — a bilingual coworking-space site rebuilt on a headless Statamic CMS.
Apex Workspace is the bilingual (EN/AR) marketing and booking site for a real coworking operator in Jeddah, Saudi Arabia — a Next.js 16 App Router frontend that renders almost every page from a headless Statamic CMS over a hand-rolled GraphQL layer.
Visit live site ↗apex.work
apex.work
CONTEXT
Apex Workspace runs 40+ private offices, 25+ hot desks, and 3 meeting rooms out of a single Jeddah location, and needed a site that could show real-time-feeling content (pricing tiers, room availability, event listings) without a developer touching code for every copy change. The frontend is built by Brackets Technology against a Statamic backend at backend.apex.work.
There is no authenticated area anywhere in this codebase — every route is a public marketing/booking page. The header's 'Login' button is a plain outbound link to a separate third-party coworking-management platform members use directly; this repo has no session handling, no user accounts, and nothing to seed a demo login with.
The repo's integration branch — the one this case study documents — is well ahead of what apex.work currently serves: the live domain's sitemap only lists the homepage and 404s on /workspaces/private-office and /contact, while integration has a diff against master of nearly 800 files and 160k+ line insertions, including the entire CMS-integration, dynamic-form, and error-handling architecture described below. Screenshots and Lighthouse numbers in this case study were measured against a local production build of integration, not the live URL, for that reason.
MY ROLE
exactly what I built — nothing more claimedR-01
Built the GraphQL data layer connecting the frontend to the Statamic CMS — a native fetch client, with queries and fetchers deliberately kept in separate folders, no GraphQL client dependency.
R-02
Migrated four separate workspace pages onto one CMS-slug-driven [slug] route, including the redirect and sitemap/nav updates needed to preserve the old URLs' SEO equity.
R-03
Built the centralized error-handling layer (structured logger, route + root error boundaries, isolated error boundaries for risky client widgets) — including a security fix to one of the CMS-integration routes that isn't detailed further here, since it hasn't reached the live production build yet.
R-04
Built the CMS-driven dynamic-form engine (widget chosen from the CMS's own field metadata) and the custom vw-based pixel-scaling system used across the rebuild.
ARCHITECTURE DECISIONS
5 decisions,each with the trade-off that drove it
A-01
One CMS-slug-driven [slug] route replaces four hardcoded workspace pages
The trade-off: any workspace slug without a matching Statamic entry now 404s outright — including, at the time this was shipped, the nav links for hot-desks, meeting-rooms, and virtual-office — with no static fallback. Worth it because valid slugs are now entirely CMS-driven, so a new Statamic entry lights up the site automatically instead of needing a new hardcoded route and component every time the client adds a workspace type. The old plural URL got a permanent redirect rather than an internal mapping table, to keep the URL space itself simple.
![The /workspaces/private-office page showing the CMS-authored headline 'Private offices built for Jeddah's most ambitious teams', a photo of the private-office floor, and a Check Availability button — rendered from the shared [slug] route](/_next/image?url=%2Fapex-work%2Fscreenshots%2FA-01-cms-driven-workspace-page.png&w=2048&q=75&dpl=dpl_7sSui3kKzvJzNJvvAm8XWbFuvUhK)
A-02
Centralized error handling with isolated widget-level boundaries
The trade-off: every catch site now has to route through a shared error/logger utility instead of a bare console.error or throw, which is more ceremony per call site. Worth it because there's now exactly one place to swap in a real log sink later, and because risky client widgets are wrapped in their own error boundary so a single failing script can't take the whole route down. This screenshot is a live example of that: the Google Maps embed on /contact throws a referrer-restriction error against localhost (the API key is restricted to the production domain), and the boundary contains it to just that widget — the address, hours, and booking form around it stay fully usable.
A-03
Native fetch GraphQL client instead of Apollo/urql/graphql-request
The trade-off: giving up a client-side cache, devtools, and generated hooks, and hand-writing TypeScript types from real query responses instead of a codegen step. Worth it for a static-content, SEO-first site rendered in Server Components: Next.js's own fetch cache already does the caching a GraphQL client would duplicate, and it drops a meaningful chunk of client JS that would otherwise ship for a feature the site never uses client-side. Queries and fetchers are kept in separate folders by explicit request rather than colocated.
A-04
Custom vw-based pixel-scaling system instead of Tailwind's default breakpoints
The trade-off: a bespoke Tailwind v4 utility layer that converts Figma pixel values into a viewport-relative calc(), plus a separate mobile variant — more moving parts than plain Tailwind breakpoints, and it's the direct cause of an accessibility trade-off: pinch-zoom is locked to make the scaling system behave consistently. Worth it for a design-led marketing site where pixel-perfect fidelity to Figma frames across viewport widths mattered more than following Tailwind's breakpoint conventions — and it ships with its own self-check script that compiles the utilities through the real PostCSS/Tailwind pipeline and asserts the emitted output, rather than trusting the CSS by eye.
A-05
CMS-first rendering with no translation fallback once a field is wired
The trade-off: once a page section is wired to the CMS, it renders exactly what Statamic returns — including blank, if an editor hasn't authored that field yet (the Arabic homepage has blank headings today because that entry is null). The alternative — falling back to an English default string — was explicitly rejected mid-project. Worth it because a silent fallback would mask missing CMS content during QA — a blank section is an obvious, actionable signal that an editor needs to author it; polished placeholder copy is not.
TESTING & CI
0
unit tests
0
E2E scenarios
No CI pipeline exists in this repo — no workflows and no unit/e2e test files were found.
MEASURED QUALITY
apex.work — live pageReachable in the last daily check
Lighthouse mobile · checked 2026-07-07 · verify ↗ (opens external site)83performanceACCESSIBILITYPartial — real, measured gaps, not a clean pass
a11y
A Lighthouse accessibility run against a local production build scored 86/100 (desktop) and 93/100 (mobile), with concrete findings: insufficient color contrast, non-sequential heading order, one link with no discernible name, and a deliberate viewport lock (maximumScale: 1, userScalable: false) that disables pinch-zoom — a trade-off for the custom vw-based pixel-scaling system, at a real cost to the standard zoom-accessibility guideline.
RESULTS
No booking-volume, conversion, or business-outcome numbers were available to measure, so none are claimed here. What is measured: a local production build of the `integration` branch scored 99/100 performance on desktop and 83/100 on mobile in Lighthouse, with a 0.9s desktop / 4.5s mobile LCP. That number describes the branch, not the live site — apex.work is currently serving an older build from `master` that predates this CMS-integration work, so it could not be measured directly.
Visit the live site ↗ (opens external site)WHAT I'D DO DIFFERENTLY
The CMS-integration work here is genuinely deep — a real GraphQL data layer, a generic form engine driven entirely by CMS field metadata, and a centralized error-handling layer that includes a security fix not detailed further here — but it shipped with zero automated tests and no CI, and the same class of bug recurred more than once across the CMS-integration routes with nothing to catch it automatically. The `integration` branch is also meaningfully ahead of what's actually deployed at apex.work: the Lighthouse numbers and screenshots here describe a local build of that unreleased work, not the live site, and that distinction is worth keeping in mind reading this page. The custom vw-scaling system is a genuinely interesting piece of engineering, but locking pinch-zoom to make it work is a real accessibility cost worth being upfront about rather than glossing over.
Next
W-07Saudi Banks →
fraud-awareness campaign site · 2023-09