TeamUp's Website: Rebuilt for Content, SEO and AI Agents in One Sprint

Today, a change to TeamUp's website starts with a sentence. Someone describes what they want. An agent makes the edit, opens a pull request, and the team checks the preview link before it merges. That workflow is why TeamUp moved.

TeamUp helps accounting firms hire accountants in the Philippines directly, with no outsourcing middleman. Their site is where firm owners book a call. We know it well. We designed and built the version that ran on Webflow. Back then, full CMS access was what the team needed. Then their needs changed. They wanted new content writing workflows, SEO and AEO (answer engine optimization) work, more control, and a site AI agents could actually work in. We moved it to Next.js in a single two-week Sprint, working with Meryl, one of TeamUp's co-founders. The new site is a lot faster too. That helps search as well.

The Challenge

TeamUp wanted to publish more and shape every page for search engines and answer engines. They wanted agents to help write and edit that content. Webflow made that hard. A visual CMS is built for a person clicking through an editor. It isn't built for an agent that needs to read content, change it, and hand it back for review.

The migration itself had to be clean. Every URL in the old 68-URL sitemap, every form, every tracking tag had to keep working. And after launch, a team that had never used GitHub had to be able to run the site.

Revisiting Our Own Decision

When we first built TeamUp's site, Webflow was the right call. The team wanted direct CMS access. They wanted to change pages without waiting on anyone. Webflow gave them that.

Their needs changed. The work they want to do now is content, SEO and AEO, done with agents. The fastest path is to describe a change, let an agent make it, and check a preview before it goes live. A visual CMS isn't built for that workflow.

So we went back to a decision we made ourselves. Webflow did exactly what we picked it for. The team just needed something different now.

The Approach: A Site Agents Can Work In

We rebuilt the site in Next.js on Vercel. The content lives in the repo, as files an agent can read and edit directly. No CMS between the agent and the page.

We built it in Tailwind with a set of reusable components. A new page is mostly content dropped into blocks that already exist. The team ships content. They don't build new components to do it.

The Sprint started Oct 5. TeamUp's team sent new copy for the About, Manifesto, Resources and Success Stories pages. The new site went live Oct 19.

Edited Through Pull Requests, Not a CMS

TeamUp's team was new to GitHub and pull requests. They wanted to learn. Today, agents handle the edits. Someone describes a change, an agent opens a pull request, and the team checks the preview link before it merges. Nothing goes live without a person looking at it first.

A Sanity setup was planned. That plan is on hold. Content in the repo, agent pull requests and preview links covered what they thought a CMS was for. The Webflow CMS gave them access. The custom build gives them the power to run content, SEO and AEO work at the pace agents allow.

Here's how that editing setup works.

Cutting Over Without Losing Anything

A new content workflow is worth little if the migration costs you the search traffic you already have. Migrations usually lose traffic in three ways: redirects that chain, canonicals that break, pages that ranked and quietly disappear.

TeamUp decided which old URLs stayed and which moved. That's a business call, so it was theirs to make. We built a keep, remove or redirect sheet with them and implemented it.

We rechecked every URL from the old sitemap on Nov 1, 2026. All 68 still resolve. 61 load at the same address. 7 redirect to their new home in a single hop. No chains, no 404s. The homepage canonical used to point at the bare domain, which redirected to www. Now canonicals point at www. The robots.txt allows the site. Lighthouse's SEO score is 100.

The Added Benefit: Speed

Speed wasn't the reason TeamUp moved. It came with the move. And it matters for search: Google looks at how fast a page loads on a phone.

We throttled Chrome to a slow phone and loaded the old homepage. The hero image took 9.7 seconds to appear. The server responded in about 15 milliseconds. The server wasn't the problem. Three things were:

• The hero image was set to lazy-load. It was the largest element on screen, and the browser treated it as something that could wait.
• Webflow's jQuery, web font loader and script chunks blocked rendering. Nothing useful could paint until they finished.
• The CRM's tracking script tied up the phone's main thread for about 3.4 seconds. A tap in that window may not register.

We took a baseline on the live Webflow site on Oct 4, 2026. Then TeamUp's content changed, so we ran the test again on Oct 13. Same tool (Lighthouse), same settings, median of three runs. The Oct 13 run is our before. On Oct 20 we ran the same test on the live new site. Lab data, not real-user data.

Page	Metric	Before (Oct 13)	After (Oct 20)
Homepage (mobile)	Performance score	36	96
Homepage (mobile)	LCP (main image)	9.7s	2.7s
Homepage (mobile)	First paint	5.2s	1.2s
Homepage (mobile)	Page weight	1.4 MB	0.44 MB
Homepage (mobile)	Requests	50	32
Homepage (desktop)	LCP	1.6s	0.6s
About (mobile)	Page weight	3.1 MB	0.46 MB
About (mobile)	LCP	3.7s	2.7s
Resources (mobile)	LCP	3.4s	2.6s
All pages tested	Best Practices	78 to 79	100

Layout shift is 0 on every page we tested after launch.

Now the honest part. Some of that score jump comes from when the scripts load, not whether they load. The CRM's tracking script and the tag manager now wait for a tap, a scroll or a few idle seconds. A lab test doesn't see them. Real visitors still download them. The tag container is the same size. We changed when the tags load. We didn't remove them.

Thirty days of real-user data is the real check. We'll add it here when it's in.

What Made This Work

Build for the workflow, not the editor. TeamUp's work is content, SEO and AEO, done with agents. So the content lives where an agent can reach it.

Revisit your own decisions. We chose Webflow for TeamUp. It was right then. When the team's needs changed, the honest move was to say so.

Build components once, ship content after. Reusable Tailwind components and content in the repo did the job a CMS was supposed to do. That may change as the team grows. For now, it's one less system to run.

Keep what already ranks. Every old URL still works, in one hop or less.

Measure before you move, then measure again. Same tool, same settings, on the live site both times. Like for like.

Be honest about the tags. Loading scripts later makes a lab score look great. Saying so is the only way the number means anything.

On Webflow, Framer or WordPress and wondering if a custom build is worth the move? The migration guide walks through how we do it, end to end. Website redesigns has more on the work itself.

Book a discovery call