Series: Replatforming a Subscription Platform · Part 7 of 10
- The Monolith Tipping Point: 6 Signs Your Platform Needs More Than a Patch
- Build vs Buy for Subscription E-Commerce: A Detailed Cost Analysis
- Transaction Fees: The Hidden Cost That Makes Platform Economics Counterintuitive
- How to Run a CTO Infrastructure Review That Stakeholders Actually Trust
- Multi-Repo vs Monorepo: A Practical Decision Framework for Small Teams
- TypeORM vs Prisma: Choosing Your ORM for a TypeScript Migration
- Platform Replatforming at Freddie's Flowers: The Decision Framework
- PHP to TypeScript: Why We Migrated a Production Subscription Platform
- Core Web Vitals as a Replatforming Success Metric: Real Before and After Numbers
- Serverless vs Containers vs EC2: Choosing Infrastructure for a Lean Engineering Team
Why Replatform at All
The impetus for replatforming is usually one of three things: the existing platform can't support the business's next stage of growth, it's becoming too expensive to maintain, or it's limiting the team's ability to iterate.
At Freddie's Flowers, the driver was a combination: the existing platform had grown organically in ways that made the subscription lifecycle logic difficult to change, and the frontend architecture made rapid customer-facing iteration slow.
Before committing to a replatforming programme, we went through a rigorous evaluation:
Option A: Incremental improvement. Refactor the most painful areas of the existing platform without a wholesale replacement. Lower risk, but potentially slower to achieve the desired outcome.
Option B: Big-bang replacement. Build a new platform in parallel, then cut over. Maximum disruption during the build; clean outcome if successful.
Option C: Strangler fig migration. Incrementally replace components of the existing platform, routing traffic to the new system piece by piece. Higher complexity in execution; lower risk at any given moment.
We chose Option C.
The Technology Decisions
Backend: TypeScript (Node.js): One language across frontend and backend, shared types between the API and the web app, a first-class AWS Lambda runtime and a much larger hiring pool than PHP. Strong typing matters most in exactly the place a subscription engine is hardest: complex state transitions.
Frontend: Next.js: The React ecosystem gave us the component architecture and developer experience needed for rapid UI iteration. Next.js specifically for server-side rendering (important for SEO and perceived performance) and its file-based routing that simplified our frontend architecture.
Database: MySQL (Amazon RDS): We kept the existing MySQL database rather than adding a database migration to an already large programme. Moving to a managed RDS instance removed the operational burden without the risk of changing engines.
What We Preserved
Replatforming doesn't mean rebuilding everything. We deliberately preserved:
- The payment integrations (Stripe and Braintree): stable, well-tested, no reason to touch
- The fulfilment partner integrations: external dependencies with their own complexity
- The email system: Brevo templates that were well-tested
Every system we preserved was one less risk in the replatforming programme.
The Non-Technical Challenges
The hardest part of replatforming isn't the code. It's maintaining two systems simultaneously, keeping them in sync during the transition period, and managing the team's confidence through a programme that feels slow before the migration completes.
Clear milestones (component X is migrated, component Y is next) and regular communication about progress were essential. The team needed to understand why this was worth the investment, not just what was being built.