Rebuilding a digital gift card platform's roadmap for 40% faster feature delivery
A 12-week alignment and architectural restructure that cut partner integration time 63%, removed 15 hours a week of manual reconciliation, and dropped sprint carryover from 45% to 12%.
The platform that had everything except direction
When I joined a digital gift card and loyalty platform as technical lead, it was already processing real transactions. The business was growing. The engineering team was capable and motivated. On paper, things looked fine.
Underneath, delivery was grinding to a halt.
Features that should have taken two weeks were taking six. Every sprint ended with carryover. The product backlog had grown past 200 items, and nobody agreed on what mattered most. The business kept making decisions about partnerships and integrations, and the technology team was permanently two months behind those decisions.
The root cause was not technical. It was alignment. The product roadmap had become a wish list instead of a strategy.
What I found in the first two weeks
I spent the first two weeks doing three things: talking to stakeholders, reading the codebase, and sitting in on every active sprint ceremony.
The stakeholder conversations turned up three problems. The commercial team had commitments to three enterprise partners that needed platform integrations not yet on the roadmap. The operations team was reconciling gift card redemptions by hand because the reporting module was incomplete. And the CEO wanted a self-serve merchant onboarding flow that had been "almost done" for four months.
The codebase told its own story. The gift card redemption engine was a monolith with no clean API boundaries, so every new integration meant touching the core engine. There was no event system, just synchronous database writes for every state change, which made async workflows or integrations impossible to build without major refactoring. And test coverage sat at 22%, so every deployment carried real risk.
The sprint ceremonies showed the rest. The team was context-switching across six concurrent workstreams. Priority disputes between product and engineering got settled by whoever was loudest in standup. And there was no definition of done that included business validation. A feature was closed when the code merged, not when the business outcome was confirmed.
The diagnosis was clear. The platform needed both a new product strategy and an architectural foundation that could support it.
The intervention: a 12-week alignment and restructure
Weeks 1-2: stop the bleeding
Before any new strategy work, we made one immediate change. We cut active workstreams from six to two.
That was the most painful conversation of the engagement. Every stakeholder believed their initiative was the most important. I ran a structured prioritization session using the technology-business alignment framework, mapping every in-flight item to a concrete business outcome. Three of the six workstreams had no clear owner, no defined success metric, and no agreed timeline. We parked them.
Weekly velocity went up 30% in the first sprint. Not because anyone worked harder, but because they stopped switching contexts every three hours.
Weeks 3-6: define the three outcomes
With the noise gone, I ran alignment sessions with the CEO, the commercial lead, and the engineering lead. We landed on three outcomes for the next 90 days.
The first was partner integration velocity: cut the time to integrate a new gift card partner from 6 weeks to 2. That directly unblocked three commercial commitments.
The second was operations efficiency: kill the manual reconciliation process eating 15 hours a week of the operations team's time.
The third was merchant self-serve: get the self-serve onboarding flow to production so the commercial team could close deals without engineering involvement.
Every backlog item that did not map to one of these three went onto a future consideration list. Not deleted, but explicitly deprioritized.
Weeks 7-12: architectural enablement
Hitting the partner integration velocity outcome meant fixing the architecture. The monolithic redemption engine was the blocker.
Instead of a big-bang rewrite, we used the strangler fig pattern. We built a thin integration adapter layer in front of the existing engine that exposed a clean API contract for all new partner integrations. The legacy internals stayed intact, and new partners connected to the adapter rather than the engine directly.
graph TD
subgraph "Before: Direct Coupling"
P1[Partner A] -->|Custom code| E1[Redemption Engine]
P2[Partner B] -->|Custom code| E1
P3[Partner C] -->|Custom code| E1
end
subgraph "After: Adapter Layer"
P4[Partner A] --> A[Integration Adapter API]
P5[Partner B] --> A
P6[Partner C] --> A
A -->|Stable contract| E2[Redemption Engine]
A --> EV[Event Bus]
EV --> R[Reporting Service]
EV --> O[Operations Dashboard]
end
The event bus, built on Azure Service Bus, handled the operations efficiency outcome at the same time. Every redemption, issuance, and reconciliation event now published to the bus, and the operations reconciliation report became a simple subscription. Zero manual work.
The results at 90 days
| Metric | Before | After | Change |
|---|---|---|---|
| Partner integration time | 6 weeks | 11 days | -63% |
| Feature delivery cycle | ~6 weeks avg | ~3.5 weeks avg | -40% |
| Manual reconciliation hours | 15 hrs/week | 0 hrs/week | -100% |
| Active workstreams | 6 | 3 | -50% |
| Sprint carryover rate | ~45% | ~12% | -73% |
| Test coverage | 22% | 41% | +86% |
Three commercial partner integrations that had been blocked for months were finished inside the 90-day window. The merchant self-serve flow went live, and the commercial team closed two new deals without a single engineering ticket.
What made this work
Looking back, the technical changes were not the hard part. The adapter layer, the event bus, the test coverage push: all of that was tractable. The hard part was the first conversation in week one, where I told a room full of stakeholders we were going to stop doing four things they each cared deeply about.
Without that willingness to focus, none of the technical improvements would have had room to matter. Architecture enables strategy. But strategy has to come first.
Work with me
Ready to discuss your architecture?
I work with founders and engineering leaders as a Fractional CTO to translate business goals into technical strategy - and execute on them. Free 30-minute Technical Health Check to start.
Book a call