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: Laravel (PHP) — The existing team had strong PHP capability. Laravel's clean architecture, excellent ORM (Eloquent), queue system, and test tooling made it a strong choice for building the new subscription engine. Going with Go or Node would have been technically interesting but introduced hiring complexity and a learning curve at a time when delivery pace mattered.
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: PostgreSQL — Migration from MySQL. Postgres's superior JSON support, window functions, and advisory locks (useful for subscription processing) justified the migration cost.
What We Preserved
Replatforming doesn't mean rebuilding everything. We deliberately preserved:
- ·The payment integration (Braintree) — stable, well-tested, no reason to touch
- ·The fulfilment partner integrations — external dependencies with their own complexity
- ·The email system — SES + 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.