High-Performance Multi-Format Preview Engine

Context

An early-stage digital agency was developing a SaaS product based on its existing social-media content production work. The goal was to turn parts of their manual design workflow into an interactive platform where users could edit graphic templates directly in the browser.

The product used React components to represent editable SVG templates, with a Next.js application and a microfrontend architecture based on Webpack Module Federation. The agency had received government funding for the project, but development was significantly behind schedule: after around seven months, the core product still had no working features.

I joined as a Senior Frontend Engineer to help bring the platform to a functional state and establish a more sustainable engineering approach.

Problem

The existing codebase had accumulated significant technical debt during the early development phase. Development had been largely independent, with limited coordination between contributors and no meaningful automated test coverage.

As a result, implementing one feature would frequently break several existing parts of the application. The problem was not limited to individual bugs; the underlying architecture and development workflow made it difficult to make progress safely.

The team was also growing, with another developer joining shortly after. We needed to improve both the technical foundations and the way we worked before continuing to add features.

A particularly important unresolved challenge was the product’s core editing experience. The platform was being built for digital agencies creating social-media content, and its main purpose was to let users create and edit graphic content directly in the browser.

A single piece of social-media content could need to be produced in several different dimensions depending on where it would be published. For example, an agency might need the same design adapted for Instagram, Facebook, mobile, and desktop, each with a different aspect ratio and resolution.

The platform therefore needed to let users edit one template live while simultaneously previewing how that design would appear in each target format. The resulting images also needed to be exportable in common formats such as PNG, JPEG, and WebP at the required resolutions.

This made rendering a core part of the product rather than simply a UI concern: the editing experience had to remain responsive while generating and displaying multiple versions of the same design.

Intervention

Establishing a workable development process

I started collaborating closely with another developer who had recently joined the project. We paired on the codebase, mapped the major problems, and created a roadmap for addressing the most disruptive technical issues.

Rather than continuing to add features on top of unstable foundations, we prioritized refactoring the core areas that were causing repeated regressions.

This allowed us to complete the main dashboard and application views while creating a more predictable foundation for subsequent development.

Introducing structured server-state management

We introduced TanStack Query to separate server state from the application’s local UI state and provide consistent data fetching and caching.

This simplified several parts of the application and made features such as infinite scrolling considerably easier to implement. It also established a clearer boundary between UI state and data retrieved from the backend.

The search functionality was developed by my colleague, while I focused on the surrounding architecture and core rendering work.

Building the multi-format rendering engine

The central product challenge was the live rendering system.

Templates were implemented as React components and edited interactively in the browser. The application therefore needed to render the same design at multiple aspect ratios while the user was actively modifying it.

I designed and implemented the rendering engine to generate the required output formats on demand. The system supported multiple aspect ratios without requiring separate template implementations for each format.

I also built the surrounding responsive interface so that the application could adapt the preview experience to the available screen size. Depending on the device and available space, the interface could switch between rendering ratios and present the relevant previews without making the editing workflow cumbersome.

This separated the concerns of template editing, rendering dimensions, and preview presentation, allowing the same underlying template to drive multiple output formats.

Outcome

Within three months, my colleague and I had substantially reworked the platform and brought the prototype to a functional state suitable for presentation.

The work resulted in:

• A working dashboard and application views.
• A more structured frontend architecture with clearer state and data-handling responsibilities.
• TanStack Query-based data fetching and caching.
• Infinite scrolling and other data-heavy UI capabilities.
• A working multi-format rendering engine for the platform’s core editing experience.
• Responsive preview behaviour across different aspect ratios and device sizes.
• A development process with substantially more coordination and shared ownership than the project had at the beginning.

Most importantly, the project moved from a prototype where new changes regularly caused regressions to a functional product that could demonstrate its core value.

Additional Context

The engagement was focused on getting the existing product into a viable state rather than replacing its overall architecture.

The existing microfrontend architecture based on Webpack Module Federation was retained. The work therefore had to improve the application incrementally while operating within the technical direction that had already been established.

The multi-format renderer was particularly important because it addressed a fundamental product requirement rather than being a standalone performance optimisation: the value of the platform depended on allowing users to create one design and understand how it would translate across the different formats required by social and digital channels.