Building in Public: Payment Reliability, Event-Driven Systems, and Tested AI

I'm a Senior Software Engineer who's spent the last 5 years building fintech and real-time systems: a UPI payment flow processing ~1,000 transactions a day, a stock-alert system serving a million users at sub-2-second latency, and streaming pipelines tracking 100,000 vehicles concurrently.

Almost none of that work is public. That changes now.

What I'm doing

Over the next year and a half, I'm building a series of open-source projects in public, all pointed at one sentence: backend engineering for payment reliability, event-driven systems, and tested AI.

Three themes, because they're where my production scars are — and where I think the gaps are:

• Payment reliability. Every team that takes payments rebuilds idempotency keys and the transactional outbox from scratch, and most get them subtly wrong. I've debugged duplicate payments in production; that experience deserves to be a library, not a war story I retell in interviews.

• Event-driven systems. Fan-out architectures, exactly-once delivery (and why it's a lie), reconciliation — the unglamorous machinery that makes financial systems trustworthy.

• Tested AI. Everyone has AI demos; almost nobody has evals. I'll be treating prompts as code: golden datasets, CI-gated regression checks, and published failure rates — including on my own tools.

First up: pytx

A payment-safety toolkit for Python. The library I wished existed when I was eliminating duplicate fund transfers in a live UPI flow. Real-infrastructure tests, a chaos suite, published benchmarks. It ships first because it's the foundation everything else here dogfoods.

What comes after depends on what I learn shipping it — that's part of the point of doing this in public.

The rules

• One project at a time. Nothing starts until the previous one ships.

• Cut scope, never quality. Every repo gets CI, strict typing, 90%+ coverage, and real-infrastructure tests from day one.

• Nothing counts until it's public. Shipped, documented, and written about — or it didn't happen.

• ~5 hours a week. This is a marathon on a budget, which is exactly why the constraints matter.

Why in public

Three reasons. Writing forces clarity — if I can't explain a design decision, I don't understand it yet. Public artifacts compound — a blog post keeps working long after a sprint ends. And accountability — this post is the commitment device.

Expect posts at project milestones: war stories from production payments, data-model decisions, and what happens when you actually measure your AI tools instead of demoing them.

Follow along here, or on GitHub.