Rebuilding Frontend Architecture: A Win for Both the Product and Tech People

Background

At Nursa, the Growth team was a hybrid unit. Engineers, marketers, and generalists all sat together, and I was one of the full stack engineers. We threw out a lot of ideas, shipped fast, and the rest of the company tended to follow whatever we tried first.

It was a multidisciplinary team that stayed in sync without losing context. Thanks to Webflow’s independent database and deployment, the team could test and iterate at the speed of light without caring about the main codebase and CI/CD. Otherwise, engineers were ready to jump in and create the integration needed between Webflow and codebase. And a whole set of tools had grown up around it over time, most of them custom-built to keep us fast.

The challenge: new features on a brittle foundation

The trouble showed up as the features got more complex. The more ambitious the product work, the more the architecture under it started to crack, and the problems stopped being things we could patch around.

Most of it came back to Webflow. It's great for static and dynamic content pages, but it falls apart the moment you push it toward real product features. We were Webflow's third largest client globally, and we kept hitting that ceiling. Something was always missing.

Under the hood, the setup had turned into a pile of fragile workarounds:

  • We couldn’t have unit tests, so no real safety net.
  • No server logs possibility, so debugging was mostly guesswork.
  • An unstable Webflow API that took production down fairly often.
  • A signup flow that leaked an API key. It had already been attacked more than once.

Nobody wanted to touch any of it. The whole team leaned on Webflow's CMS and on being able to deploy independently, and those were the exact things that made us fast. We needed a more modern, secure setup, but not at the cost of the workflow the team was built around. The real risk here was never the technology. It was that a fast, multidisciplinary team could lose its rhythm to a new tooling barrier.

The strategy: a reversible, four-phase plan

I mapped out the architectural gaps, pitched a hybrid approach to management, and led the build from there. Plenty of people on the team were rightfully skeptical of any change, so I planned it in phases where every step could be rolled back. The idea was to build confidence over time rather than bet everything on a risky big-bang rewrite.

Phase 1: the hybrid foundation (Webflow Cloud + v0)

I built a React/Next.js app and deployed it to Webflow Cloud, which runs on Cloudflare's edge underneath. That gave us something we'd never had before: a Next.js app and our existing Webflow site sitting on the exact same domain.

Not only that, we also shared components across both, the same nav, the same footer, and so on, so the two separate apps read as one product. There was no second domain and no visible handoff. For users, it was just Nursa.

Then I wired the Next.js project up to v0, and that's the part that landed with the whole team. Non-developers could now use AI to build and ship features straight on Next.js, without waiting on an engineer. The devs kept working in Cursor and Claude Code, everyone else worked through v0, and the team's day-to-day barely changed. We could suddenly build things Webflow had never let us build.

Phase 2: closing the security hole

We rebuilt our worst pain point first, the dynamic nine-step signup flow. Moving it onto Next.js secured the exposed API keys right away, let us add proper unit testing, and gave the team a concrete look at what React could do, all without touching a single SEO page.

It also let us move real backend logic into Next.js (by following BFF architecture) and retire the n8n workflows we'd been using as a stand-in backend. That brought our n8n bill down a fair amount.

Phase 3: proving SEO and performance

To show Next.js could handle SEO, I used a new business requirement as a chance to rebuild our high-traffic job search and posting detail pages. Lighthouse performance went from 60 to 99 after the rebuild.

It saved money on two fronts. Pulling data straight from our production database, instead of syncing it into the Webflow CMS, cut our CMS usage and the bill attached to it. And rewriting the search page ourselves let us drop the Algolia enterprise plan entirely, which was another solid saving.

This change perfectly aligned with the end of our Algolia enterprise plan contract. Which was a nice detail.

Phase 4: opening up the data

With the hybrid model working and the team comfortable in Next.js, the last piece was full ownership of our data like we had with Webflow CMS. I set up an open-source headless CMS directly over our internal specific database schema, so non-developers could manage content like Webflow CMS.

The impact

We were never trying to abandon Webflow. The goal was a hybrid that took the good parts of both, and that's what we ended up with: Next.js and Webflow side by side under one domain, seamless for users, with everything we'd built in Webflow over the years still intact.

  • Security: the critical API key vulnerabilities are gone.
  • Performance: Lighthouse scores went from a sluggish 60 to 99.
  • Cost: lower spend across the stack, with reduced Webflow CMS usage, the Algolia enterprise plan dropped, and a much smaller n8n bill.
  • Velocity: devs and non-devs can both build what they want on Next.js, AI-assisted, without the old Webflow ceiling.
  • Independence: leaning on our own database and using the Webflow API less cut our vendor lock-in sharply. If we ever want to move platforms or go fully React, that's open to us now.
  • Culture: we re-architected the foundation with no team friction and no deployment downtime.

And we didn't lose anything along the way. The features we'd built in Webflow still run fine, now with Next.js and v0 on top, which finally lets us build the things we'd wanted to for a long time but couldn't.