From Static JSON to Scalable CMS
Rebuilt the content system using Sanity, ISR, and webhooks to remove developer bottlenecks and speed up campaign launches across the IPO platform.
- Company
- PrimaryBid
- Role
- Senior React Engineer
- Scope
- Full ownership
- <5 min
Content updates time reduced
- Zero
Developer involvement for copy changes
- 2+ Products
IPO app + marketing website powered
Context
The Problem
In the initial build for the Deliveroo launch, static JSON was a deliberate trade-off to move fast and get the campaign live. It worked, so we kept going.
As we scaled, though, it became a bottleneck: every content change meant a full development cycle, even for simple copy updates.
Objective
The Task
Evaluate and recommend a headless CMS. Enable editors to manage content independently, support multiple campaigns, maintain performance.
Solution
Implementation
Chose Sanity for schema-as-code
TypeScript support, and webhook-based ISR. Flexible enough for our component architecture, intuitive enough for editors.
Schema design
Collaborated with design to map UI components to Sanity schemas. Document types for Issuer, Campaign, Phase. Mobile-first.
Studio
Custom input components, validation rules, preview configurations.
Performance
Sanity webhooks trigger ISR. Static performance, near instant content updates.
Architecture
Fully dynamic page building with GROQ fragments. Internationalisation enabled in Studio and schema for multi-language campaigns.
Outcome
The Impact
- 1.Content updates: hours → minutes, zero developer involvement
- 2.Campaigns prepared in parallel with development
- 3.Scaled to multiple simultaneous campaigns
- 4.Architecture later powered DSP2.0 (SoFi partnership)
Reflection
Lessons Learned
Schema design is product design.
Time upfront with the design team on patterns and vocabulary paid dividends.
Start with constraints, add flexibility later.
I made schemas too flexible at first—editors got lost. Defaults first, options where needed.
Stack