The Website Rebuild
Problem
An aging Webflow site needed replacing without losing the content team's ability to ship without engineering.
Impact
20+ pages rebuilt solo in about 1.5 weeks, with zero engineering dependency for content updates.
Technologies
Next.js, Sanity
The company site was a Webflow build the founders had outgrown. It looked dated, it didn't say what they wanted it to say, and changing it meant fighting the tool. The brief was to replace it with something that looked current and could keep up with the company.
The build
I rebuilt the whole thing on Next.js and React, with Sanity as the CMS, and shipped it in about a week and a half. Twenty-plus pages, a full set of section components, and a content schema that the marketing team could drive themselves.
The one decision worth calling out
The old Webflow site had one real virtue: the content team could edit it without going through engineering. Losing that would have been a step backward, no matter how good the new site looked. So I built the whole thing on Sanity for exactly that reason. The team kept its independence, on a platform that could actually scale with them.
The old site let the content team ship without engineering. Losing that would've been the real regression, however good the new one looked. So keeping them self-sufficient drove the whole build.
Where it landed
pages
shipped in the rebuildweeks
solo, start to deployeng dependency
for content updates, by designSpeed was a design decision here, not a brag. The faster it shipped, the sooner the old site stopped being a problem.
The internal traffic breakdown, the positioning work behind the copy, and the pre-launch benchmarks are under NDA.
