Why we're writing this
Gearabout was our most technically ambitious project of 2026. A 4,000-article archive, a fastidious editorial team and a readership that would notice — and write about — any regression in quality.
We shipped it on time and within budget. But there were decisions we'd make differently. This is an honest account.
What went well
The CMS migration
Moving 4,000 articles from WordPress to Sanity without content loss was the thing we were most nervous about. We built a custom migration script with full round-trip validation — every field in WordPress mapped to a Sanity document type, with automated checks on word count, image presence and internal links.
Final result: zero content loss, zero broken internal links. We're proud of this.
The reading experience
The long-read format — swipeable on mobile, keyboard-navigable on desktop — tested better than anything we'd shipped before. Bounce rates dropped from 67% to 31% on article pages within the first month.
The key decision: we read every long-form article ourselves during design. You can't design for a reading experience you haven't had.
The image pipeline
Gearabout's photo library is extensive. We built an automated pipeline: images upload to Sanity, get processed by Cloudinary (WebP conversion, responsive sizes, art-direction cropping), and serve from Cloudflare. LCP on article pages averaged 1.8s at launch.
What we'd do differently
We underestimated the CMS training
The technical delivery was smooth. The content team handoff was not. We allocated 4 hours for CMS training. We needed 12.
The Sanity schema we built was sophisticated — rich text with custom annotations, structured image metadata, related article linking. The editorial team needed time to build mental models for all of it.
Lesson: CMS complexity is a UX problem for editors, not just readers. Budget training time proportional to schema complexity, not feature count.
We over-engineered the article template system
We built a flexible template system with 7 layout variants. The editorial team uses 2 of them. The other 5 added scope to the build and cognitive load to the publishing workflow.
Lesson: Build for the jobs the content team actually does, not the jobs they theoretically might do. Flexibility has a cost.
We shipped dark mode as an afterthought
Dark mode was added in the final two weeks at the client's request. We implemented it with CSS variables, which was fast — but the image treatment in dark mode was never properly resolved. Hero images that worked in light mode looked flat and underexposed in dark.
We've since fixed it (editorial images now have separate dark-mode crops), but it cost us an extra sprint post-launch.
Lesson: Dark mode is a day-one design decision or it's a post-launch problem. There's no in-between.
The numbers, 3 months post-launch
- Session duration: +68%
- Newsletter sign-ups: 3× previous rate
- LCP (p75): 2.1s (down from 5.8s)
- CLS: 0.04 (down from 0.22)
- Editorial publishing time: −30% (Sanity vs. WordPress for the team)
We'd take the project again, with the lessons built in. The combination of genuine editorial ambition and a technically capable client made it one of the best collaborations we've had.