Building Money In Transit
Reflecting On The Goals Of This Newsletter, and more
Welcome to Money In Transit, the newsletter for startup founders who find themselves dragged into payments technology. I’m Alvaro Duran.
You’ve probably heard that “everyone works in sales, even if they don’t realize it”. It’s probably true. But an updated version, for online businesses, would be “everyone works in world-building, even if they don’t realize it”.
It’s the same idea, but tailor-made for a world where distribution is costless, and “content” is everywhere. Coherency in communication is much more effective online, and that usually comes from a small number of individuals, sometimes only one.
Consider sharing this post with someone who has recently started in the payment industry.
Editor’s Note: Money In Transit will be off next week, back in January.
Founders make decisions all the time. When it comes to software, that means deciding what to build, with what technology, or what to change or decommission.
These decisions need context.
Context is required because every meaningful decision can be answered with “it depends”. It is both the technical, and the business objectives involved which make a decision effective. Gathering enough context, insight that is actionable, takes both time and effort.
Most engineers tend to decide based on the context of their teams. That usually leads to local maxima that are good for the team’s standards, but which ultimately fall short of the whole startup’s optimum.
Reconciliation comes to mind. If payment applications are built as a way to fulfill a series of obligations with the customers, engineers are incentivized to ignore the technical aspects that would make their jobs more difficult, but reconciliation easier.
Engineering teams are siloed from each other, and develop, as part of their process, a kind of internal language that is incomprehensible to outsiders.
Architecting software mitigates this issue.
The role of architecting software usually falls, in startups, within the CTO’s role. But being a good manager always is at odds with being a good architect. And when there’s tension between the needs of the team, and the needs of the technical strategy, CTOs must choose between the two, the other getting neglected as a result.
I engineer payment applications. It is my job to give advice when it comes to designing and building software that moves money.
But advice is not simply throwing ideas one after another. Advice requires context. In Designing Payment Applications, I wrote:
Big Idea CEOs are happy about having just veto power on technology decisions as long as payment applications don’t cause them any headaches. Savvy CEOs don’t veto technology they don’t necessarily understand. Instead, they provide access to the multiple and overlapping contexts on which that technology operates. It’s also access that engineers most often don’t have.
People seem to think that having a vision is the hard part. I don’t agree. Thinking is the hard part.
And I’d rather get paid to think.
Then why on earth am I writing this newsletter, gratis? Isn’t that the opposite of what I just said?
World Building
Ivory tower artists are inconsequential. Unless you reach people, art is meaningless. Viewers shape art as much as art shape its viewers.
Same happens with writing. Online writing has become both the process of building the product, and building the customer for that product. It was much more effective to write The Databases of Money by slowly putting stuff out there, seeing what resonated with the people I want to serve, and making informed decisions based on that.
However, there’s a meta level (isn’t there, always?). Online, where narratives are abundant and choices are complex, writing is as much world building as it is building a product.
Early in my career, I wrote code for a living. My job was aiming at one specific obstacle, and tackling it as best and as fast as I could. But as I’ve progressed and taken responsibilities that are more complex and worse defined, I’ve realized that hard problems are not just a collection of easy, sequential problems.
Rather, they are system problems.
System problems cannot be fixed one JIRA ticket at a time, because sub-optimal steady states are held in place by feedback loops. No matter how much you try to pull away from them doing just one thing, the moment you let go it will snap back.
The only solution I have figured out for solving system problems is to write.
First, because system problems are hard to understand. Software applications always reach a complexity beyond what any single person can understand. At that point, at best, we can develop useful mental models. But in doing so, we’re going to miss key aspects of the application, and it will sometimes snap back despite our best intentions.
All models are wrong, some are useful, and only a few work in your particular case.
Second, delegating subsets of the application to other people turns into a modularization problem, not unlike architecting software. Coordination issues appear unannounced, and solving system problems involves a trade-off between the number of people involved and the effectiveness of its weakest member.
All abstractions, even human abstractions, are leaky.
So how do I solve at once the impossibility of understanding a system problem, and the coordination issues associated with breaking it down to understandable components?
By making a world.
The World Of Money In Transit
“Level 1, or world-space, is an anthropomorphically scaled, predominantly vision-configured, massively multi-slotted reality system that is obsolescing very rapidly.
Garbage time is running out.
Can what is playing you make it to Level 2”
— Nick Land, Fanged Noumena
I despise the word “niche”. I refuse to think that humans can be put in boxes. I believe instead that wealth is the product of a human’s capacity to think. Instead of thinking of myself as some kind of expert in the payment space, I’d much rather say that I’m building a reality where money moves at the speed and cost of the Internet.
I think a lot about Marc Andreessen’s recent The Techno-Optimist Manifesto. It is not based on numbers. It is not based in the past. It is a vision of what the world should look like in the future.
Regardless of how you feel about it, you feel about it. From Why Software is Eating the World, through It’s Time to Build, to the manifesto, Andreessen’s writing is about “this is what I believe” and “who is with me”.
He’s the Pied Piper of the VC industry.
I chose the name Money in Transit because it is a play on many ideas at the same time. First, it is about moving money, implicitly online. Second, it is about what happens in the background, since money in transit is the industry term for a payment that is waiting to be cleared, and is now beyond the payer’s and the payee’s control. And third, its acronym is MIT, which is also the acronym for a famous engineering school in Boston, and for “Merchant Initiated Transaction”, which is essentially a recurrent payment.
Money, movement, behind the scenes, engineering, recurrent. The building blocks of a new world.
Who am I thinking when I think about you
Initially, my target audience were CTOs at fintech companies, but I quickly noticed that they either (1) work in payments, and have developed the expertise in-house without me, or (2) don’t work in payments, and their money movement problems are much like any other startup out there.
My impact would therefore be higher if I focus on a single problem that the whole industry has, which is the down-the-line consequences of carelessly integrating with a payment platform because payments is “non-core”.
If your startup’s goal is to raise a series B or some subsequent round, the payment platform you’ve integrated with is going to kill whatever operating margins you might have. Most platforms’ pricing aggressively discount at low scale in order to aggressively overprice once you reach some scalability threshold. They know that, once you’re there, there’s no way out.
As a result, when I write, I’m thinking of those in a position to help these startups’ founders, right before they’re about to integrate with such platforms.
A key challenge for VC firms is offering value-added services (i.e., stuff other than simply money) to startups in their portfolios, so that the likelihood of success goes up. If that resonates with you, feel free to send me a DM.
I like writing. But I like building more.
Think of this newsletter as a VC funded operation. Just like software, early writing should become building blocks, and opportunities for refactoring.
Will I eventually turn this into a paid newsletter? I honestly don’t know. The experiment of putting a book out felt like raising a seed round for my tiny empire. It felt good. I’m certainly doing it again.
You can now read more. Read again. And subscribe.