How We Built and Scaled FilmWaffle to 5 Million Monthly Views

A behind-the-scenes look at how we rebuilt and scaled FilmWaffle's architecture to handle millions of users.

What do you do when you have a platform that hundreds of thousands of people use every month, but the technology holding it together is showing its age? You cannot shut it down to rebuild. You cannot afford errors. And every day you wait, the cracks get wider.

That was the situation when FilmWaffle — a film review and discovery platform — came to us. The site had a loyal, growing audience. The content was strong. The brand was established. But the technology underneath was struggling to keep up, and the limitations were starting to affect the user experience.

This is the story of how we modernised FilmWaffle from the ground up, executed a zero-downtime migration, and built an architecture that comfortably handles over 5 million monthly views. It is part of our broader library on building and scaling web applications.

The Starting Point: A Platform Under Strain

FilmWaffle had been built over several years, with features added incrementally. Pragmatic choices that served well initially were now creating problems:

Performance was declining. Page load times had crept above 4 seconds. For a content discovery platform, speed is the product.

Maintenance was painful. Simple changes took disproportionately long. Updating one feature risked breaking another.

Scaling was expensive. Traffic spikes required manual intervention, and standby capacity costs were climbing.

SEO was at risk. Core Web Vitals scores were below Google's thresholds — an existential concern for a platform dependent on search traffic.

The Challenge: Migrate Without Disruption

FilmWaffle could not go offline. Hundreds of thousands of indexed pages, active users around the clock, and revenue tied to consistent traffic meant we needed a zero-downtime migration: build the new platform while the old one served traffic, migrate all content without loss, preserve every URL, and switch over transparently.

The Architecture Decisions

Every technical decision was guided by three principles: performance, maintainability, and scalability. Here is what we chose and, more importantly, why — explained in terms any business owner can understand.

Next.js and React for the frontend. Fast loading, server-side rendering for SEO, and a smooth user experience. Think of it as rebuilding a restaurant's dining room with better seating and faster service.

A modern database architecture. We restructured the data model so queries like "top-rated films this week in this genre" ran without performance penalties — like reorganising a warehouse so popular items are closest to the loading dock.

Edge-first hosting with Vercel. Users in Edinburgh are served from a nearby node, not a data centre in Virginia. Automatic scaling handles traffic spikes. See our AWS vs Vercel vs Netlify guide for more.

Aggressive caching. Film pages and reviews are pre-generated, with only dynamic elements rendered on demand.

Structured data for SEO. Comprehensive markup helped maintain search visibility through the migration.

The Migration: Keeping the Lights On

The migration followed five phases, each designed to be reversible if something went wrong.

We built the new platform in parallel using a staging environment that mirrored production data. Every piece of content was migrated and every URL mapped — a single broken URL could mean lost search traffic. Before going live, we load-tested with simulated traffic exceeding peak levels.

The actual switch was a DNS change, with both old and new systems running simultaneously for 48 hours. For two weeks after migration, we monitored everything intensively — error rates, page load times, search engine crawl behaviour, and engagement metrics.

The result: zero downtime. Not a single user experienced an error. Search rankings were preserved, and performance improvements were immediate.

The Results: What the Numbers Show

The impact of the modernisation was measurable across every metric that matters.

Page load times dropped from 4+ seconds to under 1.5 seconds. This was the most immediately visible change. The site felt fast — genuinely, noticeably fast.

Core Web Vitals moved from amber/red to green. Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift all hit Google's "good" thresholds. This protected and improved search rankings.

Traffic grew to over 5 million monthly views. The improved performance and SEO removed the ceiling the old platform had imposed.

Infrastructure costs became predictable. Edge hosting scaled automatically, with costs growing proportionally rather than in expensive steps.

Development velocity increased. New features that previously took weeks could be delivered in days.

Lessons for Other Founders

FilmWaffle's story contains lessons that apply to any business dealing with an ageing web platform.

Do not wait until it breaks. The best time to modernise is when your platform is still working but showing strain. Migrating under pressure — when the site is actively failing — is more expensive, more stressful, and riskier.

Performance is a feature. Faster load times are not a technical nicety. They directly affect engagement, conversion, and search rankings. Every 100 milliseconds of improvement matters.

Zero-downtime migration is possible but requires planning. If your platform has active users and search traffic, you cannot afford to go dark during a rebuild. The parallel-build-and-cutover approach costs more upfront but protects your existing business.

Invest in the foundation. It is tempting to spend your entire budget on visible features. But the architecture underneath — database design, caching strategy, hosting infrastructure — determines what is possible as you grow. A strong foundation makes every future feature cheaper and faster to build.

Choose technology that scales with you. The cost difference between good architecture and cheap architecture is small at launch and enormous at scale.

Your content is your most valuable asset. Technology serves content, not the other way around.

When Is It Time to Modernise?

If you recognise these symptoms — declining performance, increasing maintenance burden, scalability concerns, SEO vulnerability — the conversation should start now. If your technology is limiting your growth, it is time to act. If it is merely imperfect but functional, optimise and plan for a future migration.

Key Takeaways

FilmWaffle was migrated from a legacy platform to a modern architecture with zero downtime and zero data loss.
Page load times dropped from 4+ seconds to under 1.5 seconds, and traffic grew to over 5 million monthly views.
The zero-downtime migration approach — building in parallel, migrating content, validating performance, and cutting over via DNS — protected existing traffic and search rankings.
Performance improvements directly contributed to better SEO scores, higher engagement, and sustainable growth.
Modernisation is most effective when done proactively, before the platform is actively failing.
Strong foundations cost slightly more upfront but make every future improvement cheaper and faster.

Frequently Asked Questions

How long did the FilmWaffle migration take?

The full project — from initial audit to post-migration stabilisation — took approximately four months. The actual cutover was completed in under 48 hours with zero visible disruption to users. The majority of the time was spent building the new platform, migrating content, and testing.

How much does a zero-downtime migration cost compared to a standard rebuild?

Expect a 20-30% premium over a standard rebuild. The additional cost covers parallel infrastructure, comprehensive URL mapping, phased cutover planning, and extended monitoring. For a platform with existing traffic and search rankings, this premium is a wise investment — the cost of lost traffic and damaged SEO during a standard migration often exceeds the premium.

Can any web application be migrated this way?

Most web applications can be migrated with zero downtime, but the approach varies by complexity. Content-heavy platforms like FilmWaffle are well-suited because content can be pre-migrated and validated. Applications with real-time features, complex user state, or transactional data require additional planning for the cutover period. The key is designing the migration with reversibility at every step.

Do I need to rebuild entirely, or can I modernise incrementally?

Both approaches work. If the underlying architecture is sound but specific components are struggling, incremental modernisation can be effective. If the architecture itself is the limitation, a parallel rebuild is usually the better path. A technical audit can determine which approach suits your platform.

If your platform is showing signs of strain and you are wondering whether it is time to modernise, get in touch for an honest assessment. We will tell you whether a migration makes sense, what it would involve, and what results you can realistically expect. Explore our full-stack web app solutions to learn more about how we approach these projects, or read our complete guide to building a web app for the full picture.