Website Redesign Behind the Scenes: How We Rebuilt zest.agency in a Month

Why we decided to rebuild

The old zest.agency was a classic one-pager of its era: black and orange, written in plain PHP, no CMS. A few service sections, client pages, a contact form, and that was basically it. It did its job for years, but at some point it stopped keeping up with the company.

There were three reasons. First, our offer had outgrown the content: performance marketing now includes AI-generated creatives, UGC campaigns and LinkedIn content, and none of that existed on the old site. Second, there was no organic acquisition engine: no blog, no English version, so nothing to rank with and nothing to show international clients. Third, technology: with no CMS, even a cosmetic copy change meant editing code.

After

Before

The new stack: React on the edge instead of PHP

The new site is a React application built on TanStack Start (a framework with server-side rendering), hosted on Cloudflare Workers, which means it renders on edge servers across Cloudflare's global network, close to the user, instead of on a single origin server. The backend (forms, recruitment, automations) runs on Supabase.

The least obvious decision: we deliberately skipped a traditional CMS. Content lives in the code repository, and every change goes through the same pipeline as code: commit, review and an automatic production deploy within minutes. For a team where content is written by technical people (or by an automation, more on that below), this removes the entire cost of maintaining a CMS panel, plugins and security updates, and gives a full history of every change.

One month of work: where the time really went

The whole project fit into one month of part-time work. The interesting part is what the time went into. The code itself came together quickly. The vast majority of the time went into:

• copywriting: every service page written from scratch around a specific client intent,
• selecting and preparing client creatives (video and statics, compression, formats),
• the English version of the entire site,
• code refactoring and load-speed work,
• an SEO audit,
• analytics and Consent Mode v2,
• automations: an AI-assisted blog and a recruitment module with automatic initial application scoring.

That's the lesson you can take from this project regardless of your stack: a redesign is a content project, not a graphic one. We started with content and offer and only then moved to mockups. Content was still the bottleneck. If your redesign schedule says "copy: one week", multiply it by three.

AI in the process: from the hero animation to the blog automation

The new site was meant to show how we work, and we work with a heavy dose of AI. You can see it in three places. First, the homepage hero: instead of a video showreel, we coded a custom animation of the agency's entire process, from brief to financial result. Second, the AI creatives page with materials we produced for clients.

Third, and most measurable, is the blog automation. Twice a week, with no human involved, it runs a full cycle: Google Search Console data analysis and keyword research, topic selection, an article in Polish and English, illustrations in a consistent style, quality checks, publication and a post on the company LinkedIn page. A human only gets an alert when something goes wrong. The article you're reading happens to be written "by hand", but the two next to it on the blog were most likely produced by the automation.

What our own redesign taught us

A few takeaways you can apply to your own project at any scale:

• Start with content; mockups come later. The old site's biggest problem was the content vacuum; its look came second.
• Benchmark the old site before switching it off. Make a full export of Search Console and GA4 data and save PageSpeed results and screenshots: after the redesign you'll use them for comparisons. A UX audit of the old site will also help you list what to fix in the new one.
• Treat speed as a requirement from day one. Edge rendering, media compression and lazy loading are architectural decisions that are hard to bolt on later. Google sets out the thresholds for a good result in its Core Web Vitals documentation: LCP within 2.5 s and CLS of 0.1 or less. After launch, our homepage has an LCP of 0.7 s on desktop.
• Plan language versions from day one. Adding them later doubles the content work.
• Automate publishing. If adding an article requires a developer or a fight with a CMS panel, the blog will quietly die within a month.

Rebuilding your own website is a credibility test for an agency: as a digital marketing agency we advise clients on websites, campaigns and analytics every day, so we treated our own site like a client project, with a brief, a schedule and quality control. We collected the numbers (99/100 in PageSpeed Insights on desktop, LCP 0.7 s, TBT 11 ms, CLS ~0, and content rendering in ~1.4 s on mobile) in a case study of this build, and if you're planning a similar project, see how we approach web design and development. And speaking of analytics: if you want to know how much data you actually collect after your own redesign, see our articles on Consent Mode v2 and the marketing dashboard.