SUBSCRIPTION MANAGEMENT: Block Backstop
[002] Business Problem
Elevated support and dispute volume — Wrongful charges during cancellation windows drive customers straight to support calls or formal disputes, both of which carry real operational cost and erode trust in the platform.
[003] My Role
I joined this subscription-management project at its inception, designing the original backend architecture with no prior implementation to build from, and have shaped it through three major rebuilding stages since as it grew into a larger, multi-endpoint experience involving several technical disciplines and a third-party vendor.
Within that larger effort, I served as tech lead on Block Backstop — a safeguard that blocks a subscription charge from firing while a cancellation is still processing with the merchant or third party. The idea itself is simple: buy enough time for the cancellation to take effect. Getting there was not — it required a deep, intentional understanding of the entire system's dependencies, careful sequencing of implementation, and end-to-end testing against existing functionality to make sure nothing broke along the way.
Beyond the technical build, I owned the full scope of delivery: assessing level of effort across competing approaches, prioritizing which pieces of the feature needed to ship first, and negotiating timelines with stakeholders to keep the project realistic without losing momentum. I led a team of four engineers through the feature's technical design and implementation, and the work ultimately scaled to 35+ of Capital One's largest merchants.
[004] Approach
Context
Block Backstop was built on top of a subscription-management system still scaling toward full rollout — so any misstep risked disrupting a live experience already reaching customers, not a system safely isolated in development. I ran the project with agile methodology, deliberately front-loading full context for new engineers and mapping the flow of work, level of effort, and sequencing before writing any code.
The real question I kept coming back to before any code got written: what happens if we get the order wrong?
Understanding the System, Then Sequencing the Build
By the time Block Backstop started, the surrounding system had grown into something built by four teams and dozens of engineers, each owning their own piece of the experience. Only a handful of people held the full picture — so before I could make any real sequencing decisions, I had to build that picture myself: how the pieces depended on each other, where a change in one place could quietly break something in another, and what had to be true before the next piece could safely be built.
Leading the Team
Most of the engineers on this project hadn't worked in this codebase before, so I couldn't assume they'd know where the risk was — I had to make sure they saw it the way I did. We started running whiteboard sessions most mornings: I'd draw out the design, and we'd walk through it step by step together. It became one of the most important habits on the team — not just for catching problems early, but because it invited everyone to push back and ask how their piece fit into the bigger picture, instead of quietly building in a corner and hoping it lined up.
When something in the sequencing got genuinely tricky, those sessions are usually where it surfaced — not in production.
Testing Against a Live System
Testing moved through several layers from unit tests to component and live-dependency level, where I could see how Block Backstop actually behaved against the systems it depended on. From there, I ran full end-to-end testing live with stakeholders on tech and product sides, walking through the experience step by step with real test data and validating what was happening on the backend at each stage.
New functionality needed detailed scenario coverage, but just as important was retesting everything that already existed. I tested for the full range of customer behavior, not just the expected path: error states, edge cases, and different customer roles. That included validating the block-removal flow itself — an internal safety net that releases a block once it's no longer needed, so a customer never gets stuck in a state the system forgot to clean up.
[005] Results
Block Backstop shipped without breaking any of the existing subscription experience it was built on top of — the rigor in sequencing and testing paid off exactly where it mattered. The safeguard, along with its corresponding block-removal flow, scaled to 35+ of Capital One’s largest merchants, closing the timing gap that had left customers exposed to wrongful charges during cancellation.
Latest Project
