Doubling Down On The Engineers of Payments
Money in Transit will be from now on The Payments Engineer Playbook
I have a dilemma.
This is not your typical me-telling-you-something-about-payments article. But I hope you’ll stick around to figure out what it is I’m talking about.
Here’s the dilemma.
Now that my open source payments library is in alpha, I’ve started building an e-commerce site to test it. I’m following the most popular tutorial I could find on how to build one.
The problem is, that tutorial is a monstrosity. Every now and then, the guy does something absolutely terrible. He imports * from file. Or overloads a CSS class named bg-dark with light green. Or cluelessly introduces N+1 queries.
And every time that happens, I just stop.
I close my eyes.
And breathe.
Only then can I continue. Until it happens again.
I just want to follow the work of someone who has done it, with hundreds of thousands of views as a proxy for quality.
How hard can it be?
When I started this newsletter, I was just messing around.
I’ve been building money software for so long, I thought it could be useful to turn that expertise into 1000-word articles that I wouldn’t be too embarrassed to share.
But the data is clear: what you want from me is technical. What you’re here for, what you read more of, like, and share, is the design patterns to build payments technology.
Almost 50 articles later, Money in Transit has a life of its own. I’ve written a book, I’ve hit the front page of Hacker News a few times, and I’ve become one of Kiwi.com's Tech Ambassadors.
My dilemma is this: should I double down on how to build payments software?
Welcome to Money in Transit, the newsletter that dives deep into the technology that moves money around. I’m Alvaro Duran.
I post weekly articles on how to build money software that is correct, performant, and on time.
Sounds impossible? Then better subscribe to find out how to do it.
Most advice on building domain-specific software is too shallow.
That means it is likely wrong. As Marc Brooker eloquently put it, “Building systems out of multiple components allows components to be optimized for the properties that matter to them”.
Generic software practices will render generic software outcomes.
In an industry where 66% of technology projects end in partial or total failure, generic is a recipe for disaster.
My thesis is this: some of that generic advice is applicable for payments technology. But not all.
Responsible engineers must figure out which advice is useful, and which isn’t.
Following that crappy tutorial taught me that we don’t have the right information to begin with. After decades building payments, that information exists, but it is not discussed in public. And we’re independently reaching local maxima that we don’t feel the need to escape from.
It’s about time someone does something about it.
Some of you are reading this because I promised I was going to do a workshop on how to build enterprise software in Python.
Well, here it is.
Over the next few weeks, I’m going to show you, in as much detail as I can muster, how I envision, design, and build money software. The kind of enterprise software I’m deeply familiar with.
You know? Like why you should separate PaymentIntent from PaymentMethod, just like Stripe does.
Or why idempotency is a fairy tale, unachievable from the inside of a service, no matter what Stripe does.
Over the next few weeks, I will put together a library of software design articles that will culminate in a multi-hour long workshop, streamed online, to anyone who wants to attend, for free. It’ll be called The Payments Software Workshop.
You can already sign up for The Payments Software Workshop via this form
I have only one small favor to ask.
Spread the word.
If you know someone building payments software.
If you know someone interested in building enterprise software in Python.
If you know someone who wants to enter the software industry on the right foot.
Let them know.
Let them know about Pizza Place Payments. Let them know about Keeping Up With The Databases. And let them know about The Taxonomy of Payment Methods.
And let them know that what is out there isn’t good enough.
But help is on the way.