[Your Name] · [Email] · [Phone] · [City, ST]
April 21, 2026
Dear Hiring Manager,
I'm applying for the Software Engineer role on your Payments API team. Patrick's 'writing is thinking' essay and your public work on idempotency keys and webhook delivery are the reasons I've spent the last four years biasing my own work toward well-written APIs and explicit failure modes. I'd like to bring that craft to a team where the default cost of a bug is other people's money.
At Plaid I owned the redesign of our webhook delivery subsystem — the same shape of problem your team solved with the /events endpoint. We were losing ~0.4% of webhook events during issuer outages, which sounds small until you remember that every lost event is a partner who doesn't know whether a payment succeeded. I replaced a single-region Postgres queue with a partitioned, idempotent delivery pipeline using Kafka and a signed-offset ACK protocol. Delivery success moved from 99.6% to 99.993%, and — importantly — the public API contract didn't change: partners got the fix without reading a migration guide. I wrote the post-launch memo as a 9-page design doc that's still the onboarding reference for the team; I'd happily share it.
Before Plaid I was the third engineer at a Series A payments startup where I wrote the original Ruby SDK, the docs site, and the three-line Stripe-style quickstart. I learned there that developer experience is a product, not a garnish — the difference between a 9-minute and a 40-minute time-to-first-charge is the difference between a customer and a churn. That's the sensibility I'd want to bring to Payments API, especially as Stripe expands its multi-currency and local-methods surface where the 'first integration hour' gets harder, not easier.
I'd welcome a 45-minute technical conversation about where I'd focus in the first 90 days — and I'm happy to send a short written take ahead of the call on a trade-off I'd reconsider in the current /events retry semantics. Flexible on timing.
Sincerely,
[Your Name]