Skip to content

Frontend Engineering

Website Development

CMS Development

54Journal

54Journal is a digital editorial publication focused on African photography, visual storytelling, and creative culture.

In 2024, I took ownership of the original frontend implementation and Sanity CMS for an earlier iteration of the platform. My responsibility covered developing the website's frontend and establishing its content management foundation.

After completing my involvement, I handed the project over to the client's engineering team, who assumed responsibility for continued development and subsequent changes.

Live preview(opens in a new tab)

Project details

Project type
Digital Editorial & Publishing Website
Role
Sole Frontend & CMS Developer
Engagement
Contribution
Period
2024
Technologies
  • React
  • React Router
  • TypeScript
  • Sanity CMS
  • Tailwind CSS
  • Vercel Analytics
  • Vercel

Context

Project context.

The platform was created around the broader goal of showcasing African photographers, visual artists, and their stories to a wider audience.

A content-driven website needed to support two distinct experiences: a public-facing editorial interface for readers and a content management environment for the team responsible for publishing.

My involvement focused on implementing the initial technical foundation for those experiences.

Project setting

My contribution took place in 2024, before the platform's subsequent branding and development changes.

The website now publicly known as 54Journal has evolved since that initial engagement. This case study focuses on the frontend and CMS work I personally delivered, not features introduced by the receiving engineering team.

The current website should not be treated as an exact representation of the frontend delivered during my engagement.

Problem space

  • Presenting visual and editorial content

    A photography-focused publication needs a frontend capable of presenting written stories alongside visual material, while keeping content accessible and easy to explore.

  • Managing content without developer involvement

    The editorial team needed a content management solution that would allow website information and editorial content to be maintained without requiring direct changes to the frontend code.

  • Establishing a foundation for continued development

    The initial implementation also needed to be handed over to the client's engineers, who would take responsibility for subsequent development and maintenance.

Target users

  • Readers interested in African photography and visual culture.
  • Photographers and visual artists whose work is featured.
  • Editorial staff responsible for managing published content.
  • The engineering team responsible for ongoing development.

Contribution

My contribution.

Sole Frontend & CMS Developer — Initial Implementation

I owned the frontend development and original Sanity CMS implementation during my involvement with the project.

My responsibility covered the technical implementation of the public-facing website and its content management foundation, followed by transitioning development to the client's engineering team.

  1. Owned the Initial Frontend Development

    I was responsible for developing the original frontend implementation for the editorial platform.

    The work involved translating the requirements of a content-focused website into its frontend experience and integrating that experience with the content management system.

    The goal was to provide a website through which the publication could present its stories and visual content.

  2. Implemented the Original Sanity CMS

    I implemented Sanity as the website's content management system.

    This established the CMS foundation used to manage content separately from the application code.

    The integration allowed the frontend to consume CMS-managed content rather than requiring editorial information to be maintained entirely through hardcoded application changes.

  3. Connected the Frontend and Content Management System

    I worked across both the frontend implementation and CMS integration.

    Owning these areas together gave me responsibility for how content maintained through Sanity was represented in the website's public-facing experience.

    This work connected the content management environment with the website's rendering layer.

  4. Handed Over to the Client's Engineering Team

    After my involvement ended, responsibility for continued development moved to the client's engineering team.

    This marked the completion of my initial implementation engagement.

    Subsequent website changes, additional features, and ongoing maintenance fall outside my contribution unless separately documented.

Scope of ownership

54Journal represents an earlier frontend engineering engagement where I owned both the public website implementation and its original Sanity CMS.

The project demonstrates experience working across frontend development and content management, delivering the initial technical foundation for an editorial platform, and transitioning responsibility to another engineering team.

Delivering an implementation and owning its ongoing evolution are different responsibilities.

Implementation

Technical breakdown.

The project combined frontend application development with a headless CMS architecture.

Sanity provided the content management layer, while the frontend was responsible for presenting that content to website visitors.

My involvement covered both sides of this frontend-to-CMS relationship.

  1. Frontend Application Development

    The frontend provided the public-facing interface for an editorial website centered on stories and visual content.

    The implementation required coordinating the website's interface with the underlying content structure.

    The original frontend framework, routing implementation, component architecture, and performance decisions would need to be verified against the 2024 source code before documenting them in greater technical detail.

  2. Headless CMS Implementation

    • Sanity CMS

    Sanity was used to separate content management from the website's frontend code.

    I implemented the original CMS and its connection to the website, establishing the basis for managing editorial content through a dedicated platform.

    The exact original document schemas, field structures, and Studio customizations have not been independently verified and are intentionally excluded from this account.

  3. CMS-to-Frontend Integration

    • Sanity CMS

    A key part of my responsibility was ensuring that content maintained in Sanity could be consumed and presented by the frontend.

    This connected two important aspects of the product:

    The integration formed part of the initial implementation delivered before the engineering handover.

    • The content management experience used by the editorial team.

    • The public website used by readers and visitors.

Outcomes

What the work delivered.

My contribution delivered the original frontend and CMS implementation during the project's earlier development stage.

The engagement concluded with responsibility for continued development moving to the client's engineering team.

  1. Deliverable

    Initial Frontend Implementation

    Developed the original frontend for the editorial platform, providing the public-facing application required for presenting its content.

  2. Deliverable

    Sanity CMS Foundation

    Implemented the original Sanity CMS and integrated it with the frontend, establishing a managed content architecture for the website.

  3. Outcome

    Engineering Handover

    Completed my involvement and transferred responsibility for further development to the client's engineering team.

    The platform has since undergone additional development and branding changes outside my original scope.

    The engagement took place in 2024. Exact dates, original architecture details, and measurable performance or publishing outcomes are not available for verification.

    The current website demonstrates the publication's present direction, but should not be treated as an exact representation of the frontend delivered during my engagement.