RSG — A Website Rebuilt
Website Design & Development
Real Serious Games
Payload CMS rebuild
Design, development & UX
Rebuilding with what the first version taught me
Keep the ambition. Rebuild the foundation.
The RSG application had already been deployed and working, but the first build exposed limitations in its data architecture, content model and ability to adapt as the business changed.
I rebuilt the application around a more mature Payload CMS v3 architecture, retaining the visual character while improving how the website is structured, edited, extended, deployed and ultimately handed over.
.webp)
A working application, reconsidered
The second build started with better questions.
The first version proved the concept. The rebuild focused on what would make the application easier to maintain, reshape and operate over time.
That meant revisiting the data architecture, rebuilding the content system, expanding Payload beyond its defaults and treating deployment and ownership as part of the product itself.
.webp)
A working deployment was not the finish line.
I successfully deployed the earlier application to my private infrastructure in January 2025, but the project had already revealed enough structural limitations to justify rebuilding it properly.
.webp)
Design the data before redesigning the interface.
With the business restructuring, the previous analytics-led assumptions were no longer reliable. The rebuild started from the content and data model so the interface could adapt to changing priorities rather than preserve outdated ones.
.webp)
Use the stable platform to simplify the architecture.
The original project began while Payload v3 was still in beta. By the time the stable release matured, I had enough practical experience with the first implementation to remove bloated structures and rebuild around a cleaner model.
.webp)
Make the structure deliberate and type safe.
The rebuilt application moved toward a clearer TypeScript-backed architecture, with the CMS collections, globals and reusable components organised around the actual content requirements of the site.
.webp)
Build pages from a reusable system.
The CMS exposes a growing library of purpose-built blocks for content, media, cards, forms, animation, calls to action and other recurring interface patterns.
.webp)
Let editors shape pages without rebuilding them.
Pages are composed from reorderable content blocks, allowing sections to be created, removed and rearranged while keeping the underlying application architecture intact.
.webp)
Reuse components without making every result identical.
Blocks support nested structures, style variations and targeted overrides so the same component system can produce substantially different layouts without duplicating the underlying implementation.
.webp)
Edit the content while seeing the result.
Payload’s Live Preview connects the editor directly to the rendered website, reducing the gap between changing structured content and understanding how that change behaves on the actual page.
.webp)
Bring search metadata into the publishing workflow.
SEO titles, descriptions, metadata images and previews are managed alongside page content, making search presentation part of the editorial process rather than a separate technical task.
.webp)
Optimise assets as part of the CMS workflow.
The media system converts images to WebP and generates appropriately resized assets using Sharp, reducing the need for editors to manually prepare multiple versions before publishing.
.webp)
Make basic image preparation available inside Payload.
Editors can crop images and define focal points directly within the media workflow instead of returning to an external image application for routine adjustments.
.webp)
Move routine website management into the CMS.
Redirects and configurable forms are managed through Payload, giving the application reusable operational tools without hard-coding every workflow into individual pages.
.webp)
Make targeted production adjustments without rebuilding everything.
I added controlled style overrides using Tailwind classes, component-level configuration and custom CSS, allowing specific presentation changes without altering the global design system or immediately redeploying the application.
.webp)
Extend the CMS when the experience requires more.
The project includes custom blocks, Rich Text extensions, smooth scrolling and interactive 3D experiences using Three.js and React Three Fiber rather than limiting the site to Payload’s standard feature set.
.webp)
Make the application architecture visible.
The current workflow connects local development to GitHub, Coolify, PostgreSQL and MinIO on private infrastructure, documenting how source code, deployment, data and media work together in production.
.webp)
Design for ownership beyond my infrastructure.
I mapped migration paths from the current environment into RSG-managed Azure infrastructure, including the application, PostgreSQL database, media storage, deployment and domain configuration.
.webp)
Keep old links useful as the website evolves.
Redirect management provides a straightforward way to point outdated URLs toward their current destinations as pages, services and site architecture change over time.
.webp)
Make individual pages private when required.
Pages can be configured as private content, requiring authentication on the frontend and giving the same application a controlled way to support restricted material.
.webp)
Use Payload as a foundation, not a ceiling.
I added project-specific controls for sticky and scroll behaviour, parallax configuration, flexible column sizing, custom classes and nested editor blocks, extending the CMS around the needs of the application rather than forcing the application around the defaults.
The rebuild reached beyond the interface
Experience, architecture, ownership.
The interface
The visual character remained recognisably RSG while the system underneath became substantially more flexible.
The application
Reusable blocks, typed content, nested structures and project-specific extensions replaced the limitations of the earlier model.
The infrastructure
Deployment, storage, database architecture and migration were documented as part of the product rather than left as an afterthought.
Related Projects
Loading archive itemsExplore HZ Designs & Project Archives - A curated collection of design projects, case studies, and creative work.
Explore HZ Designs & Project Archives - A curated collection of design projects, case studies, and creative work.
Explore HZ Designs & Project Archives - A curated collection of design projects, case studies, and creative work.