Atlas Content Grid

Problem

Marketing teams needed campaign pages faster, but the existing approach depended on developers stitching together one-off layouts. That slowed launches, created inconsistent page structures, and made performance harder to maintain as content grew.

Solution

I built a block-based publishing system where editors could assemble pages from reusable content modules instead of requesting custom templates for every campaign. The platform handled page composition, previewable content states, and analytics-friendly page structures without turning the frontend into a hard-to-maintain CMS wrapper.

Tech

• Next.js for server-rendered landing pages with strong performance and flexible routing.
• GraphQL to expose structured block data cleanly to the frontend and avoid overfetching.
• PostgreSQL for relational content modeling, version history, and reliable editorial workflows.

Key Decisions

• Modeled pages as ordered content blocks rather than fixed templates so new campaign types could reuse existing components.
• Kept presentation concerns in the frontend and content structure in the backend to prevent the CMS layer from dictating UI behavior.
• Designed the schema around predictable analytics hooks so marketing could track sections and conversion points consistently across pages.
• Optimized for rendering speed early, because a publishing tool that slows page performance creates its own business problem.

Outcome

• Reduced dependence on engineering for routine landing-page launches.
• Made campaign pages more consistent to maintain and easier to instrument.
• Created a platform that could support new content variations without rewriting the page architecture each time.