- React
- Apollo Client
- 6-Week Sprint
Deliveroo IPO Platform: A 6-Week Sprint
Rebuilding an investment platform from Vue to React in 6 weeks while delivering 50,000+ registrations and £50M in investments for one of the UK's biggest IPOs
- Company
- PrimaryBid
- Role
- Senior React Engineer
- Timeline
- 6 weeks
- 50,000+
Subscriptions in 2 weeks
- £50M
Total investment volume
- 6 weeks
From Vue to React rebuild
Context
The Challenge
PrimaryBid had an existing IPO platform built with Vue and Vuex that had been working well for smaller campaigns. However, the Deliveroo IPO—one of the most anticipated public offerings in UK tech—was scheduled to launch in just 6 weeks.
During testing of the Vue application, critical issues emerged. At the same time, there were intense internal discussions about modernizing the entire tech stack—moving from Vue to React on the frontend and rebuilding services with NestJS microservices on the backend.
The decision was made: rebuild the entire platform in 6 weeks. No room for error, no possibility of delay. The stakes were enormous—both for our users making significant financial decisions and for PrimaryBid's credibility in the market.
Delivery
The 6-Week Sprint
The Reality
I worked in close partnership with the Technical Director to meet a fixed delivery deadline. I had full ownership of the frontend and contributed to architectural decisions, balancing speed, correctness, and long-term maintainability under significant time pressure. Days regularly stretched until 3am.
Stack Selection: React · Apollo · CSS Modules
The frontend stack was chosen to minimize execution risk under a fixed deadline. React provided a mature ecosystem and predictable delivery. Apollo Client enabled efficient GraphQL state management and caching, while CSS Modules ensured locally scoped styles with zero runtime cost—important for performance under high traffic.
Content Strategy: Static JSON as a Deliberate Trade-off
Campaign content was initially served from static JSON to decouple delivery from backend readiness and reduce iteration time. This decision intentionally favored speed and reliability, with a clear path to evolve the system post-launch—later realised through a CMS migration.
Testing Strategy: Deferred, Not Neglected
Given the volatility of requirements during the sprint, we prioritised functional completeness and correctness of the user journey. Automated tests were added once flows stabilised, avoiding constant rewrites while still ensuring confidence before peak traffic.
User Flow
Building the Investment Journey
From high-stakes IPO launches to foundational design systems, I build frontend systems that balance speed, quality, and long-term maintainability under real-world constraints.
Engineering
Key Technical Highlights
State Management with Apollo
- Apollo Client used as the primary client-side state layer (user state, step progression, derived data)
- Entire registration and subscription flow handled client-side, with no server calls until completion
- Custom hooks driving validation, progress, and next-step resolution
- Client-side validation ensured correctness; final validation enforced server-side in NestJS
Why this mattered:
Keeping the entire flow client-side until completion reduced backend coupling, improved perceived performance, and made a complex multi-step journey predictable and easy to reason about.
Component Architecture
Built reusable components with clear separation of concerns. Each phase of the user journey was a distinct route with shared UI components but phase-specific business logic.
- Composable, atomic component design with clear separation of concerns
- Shared UI primitives with phase-specific orchestration logic
- Built for flexibility under time constraints, later evolving into the form component library
Why this mattered:
It allowed us to move fast under pressure without sacrificing flexibility, while laying the groundwork for a scalable, reusable system beyond the initial sprint.
Testing Strategy
- Fast iteration first: Features were built and reshaped rapidly during the sprint, with the understanding that tests would quickly become obsolete.
- Stabilize → then test: Once flows and APIs stabilized, we added coverage where it mattered most.
- Unit tests (Jest): Core business logic, utilities, and stable pure components
- Integration tests (React Testing Library): Critical user interactions and form flows
- E2E tests (Cypress): End-to-end coverage of the full investment journey across all phases
Performance Under Pressure
We expected massive traffic spikes. Code splitting, lazy loading, and aggressive caching ensured the app remained responsive even during peak registration periods.
Outcome
The Impact
From 6-week sprint to enterprise platform:
- Initial launch: 50,000+ subscriptions and £50M+ in investments processed in 2 weeks
- Reliability under pressure Platform remained stable during peak traffic for a highly anticipated public IPO
- Business impact Successful delivery contributed to PrimaryBid’s credibility during a critical market event
- Technical foundation: Established frontend patterns that later supported further product evolution
- Team enablement: Shared architectural context and decisions to onboard additional engineers post-launch
Reflection
Lessons Learned
Ship fast, iterate smart.
We made pragmatic technical decisions (like static JSON) to meet the deadline, knowing we'd improve them post-launch. Perfect is the enemy of shipped.
Close collaboration under pressure works.
Working directly with one backend engineer and participating heavily in architectural decisions created alignment and speed that a larger team wouldn't have achieved.
Technical debt should be intentional.
We knew the JSON approach was temporary.Planning for future iteration from day one made the eventual CMS migration smoother.
Scale requires different thinking.
Moving from campaign tool to enterprise platform meant thinking about maintainability and team knowledge sharing—notjust features.
Deep ownership creates opportunity.
By owning the platform from its 6-week sprint through to DSP2.0, I gained deep knowledge that made me valuable as the team scaled.
Stack