The simplification layer that shipped a rewrite's outcome without the rewrite

Role

Engineering Manager, credit in checkout

Span

Recommendation owner for how the credit domain would position itself in a ground-up rewrite of PayPal's checkout

Scale

Every credit product PayPal surfaces at checkout

Headline outcomes

Shipped on the go-to-market deadline · full credit parity from day one · the pattern replicated by other domains

In 2023, PayPal rebuilt its checkout architecture from the ground up, and I was the engineering manager responsible for recommending how the credit domain should live in the new system. My team was energized. Years of accumulated interface debt had piled up behind our credit logic, and this was the rare clean slate that let us walk away from it. The obvious ask was a brand-new interface API that made data-driven decisions about which credit products to surface. It was a technically sound ambition. What worried me was the timing. The business had set an aggressive next-quarter deadline to go to market, inside the most sweeping checkout change the company had attempted in years, in a system that sits directly on top of payments, leaving little room to absorb a surprise.

The choice, as it had been framed for me, was binary: migrate the existing debt into the new architecture, or rewrite the credit interface outright. Neither was right. Migrating meant carrying years of tangled logic into a fresh codebase on day one. Rewriting meant betting a payments-critical launch on brand-new code with no time to prove it. Rather than starting from what we wanted to build, we worked back from what the new checkout codebase actually needed from credit. It needed one clean endpoint that handed checkout everything necessary to render a credit offer, and nothing more.

I proposed building that endpoint as a deliberate simplification layer over the existing legacy system. It was throwaway work by design, an abstraction sitting on top of code we already planned to replace. Building it forced the team to map every business case our credit logic quietly serviced before anyone touched the new architecture, so the landmines surfaced as design notes instead of production incidents. When my engineering leads pushed back, watching partner teams do full rewrites while we built scaffolding, I ran a capacity-versus-runway exercise with them: the scope of the right build on paper, set against the weeks we actually had. We did not have the capacity to ship something we would be proud to own on that timeline. To prove I was protecting the vision rather than quietly killing it, I wrote the long-term goal into the architecture decision record, a committed path to retiring the legacy controller for the real target state, and put a standing weekly working session on the calendar to keep that goal alive.

We shipped on the go-to-market deadline. The mapping exercise had pulled undocumented business logic and flows that had not been exercised in years into the open, before any of it could become a production incident, and those findings fed directly into the next design. We entered the new checkout paradigm with full credit-product parity from day one, every credit offering universally compatible, while peer groups were still mid-rewrite. And the layer traveled in both forms: other teams integrated directly against it as consumers, and other domains copied the simplification-layer approach to de-risk their own moves into the new architecture.

Asking engineers who had waited years for a clean slate to build something designed to be discarded was harder than any of the architecture, and it took trusting that the throwaway bet was the fastest safe way through. There is more to that conversation, and to why the bet paid off, than fits here. If it resonates, I would genuinely enjoy comparing notes. Find me on LinkedIn or email me directly.

Back to selected work