Elon Musk has talked about implementing payments in Twitter, implementing his full vision for X.com, the company that with narrower focus became Paypal. It’s an excellent idea. But the implementation path has major obstacles he’ll have to overcome.
I have personally seen multiple efforts by tech teams inside and outside the fintech industry get hopelessly stuck in the swamps trying to implement “simple” things like prepaid debit cards, or even “just” rewriting their software using tools less than forty years old. I have also watched with amusement as the obsession with crypto technology continues to inspire major projects doomed to fail at the Fed, exchanges and a variety of prestigious banks, not to mention countless startups. I trust Mr. Musk will continue his results-driven practice by ignoring all this and drive towards a successful implementation of Twitter payments and banking.
The Huge Benefit of Starting with Twitter
Most companies you might start are classic one-to-many companies, i.e., there’s one of you selling to (you hope) many customers. There’s another kind of company, many-to-many. The company is in the middle, attempting to match many people who want something with many people who have something. E-Bay is a classic example of this kind of business, which is sometimes called a “network effect” business. These are really hard to start, because buyers want to go to a place where there’s lots for sale, and sellers only want to go to places where there are lots of buyers. How do you get such a thing started from scratch? It’s hard!
Here's the good news: Twitter is somewhat like a one-to-many business like publishing today. But because it doesn’t itself make what it sells like a classic newspaper does, it’s really a many-to-many business like Facebook, with readers using it because they like the writers they can find and follow on it, and writers using it because there is a large potential audience of readers a.k.a.followers. It has well over 300 million active monthly users!
This is good news because the main barrier of a P2P financial business – getting a large base of users with your app – has already been met and overcome.
The Danger of Typical Technology Methods
I’ve been privileged to spend a couple decades meeting and interacting with smart, accomplished software people who are doing new things. I’ve learned a great deal, both models that work and tendencies to avoid. I’ve written the observations in multiple books.
Banking built on Twitter should be a pretty simple application. But experienced people want to apply their often-inappropriate experience to building the software, and smart people too often want to prove how smart they are by following the latest tech fashions. In either case, the application suddenly becomes really hard to build.
In addition to my tech investing experience, I know the difficulties from personal experience in the world of credit card software. The world of existing issuing and acquiring systems is incredibly complex, and most attempts to build new ones fail. The experts can’t imagine anything different, and the newbies blast ahead with their wonderful modern ideas building great-sounding systems that don’t work. It’s a solvable problem, but the rare combination of in-depth knowledge of the existing systems and the ability to use methods that are modern, powerful and unfashionable is required.
Here are some of the main issues.
Modern people will want to assure that the system is “scalable” by using ridiculous things like microservices.
Modern people will want to leverage the powerful new blockchain technology – something that is amazing for Bitcoin but thousands of times worse than anything else for corporate-controlled systems.
Traditional people will want everything centered on exclusively on DBMS, avoiding powerful tools like document-centered and memory storage to enhance the solution.
Smart people tend to be highly language-focused, instead of meta-data and abstraction oriented.
Nearly everyone will want a great set of requirements and a plan for how to meet them. The trouble is you can never know all the real-world requirements of a system you have yet to build! So an approach based on post-hoc design works best.
Recognize that "building" is the wrong metaphor for creating software; the reality is that software is mostly changed. A whole set of powerful methods for building high-quality software quickly with maximum speed emerges from this.
I hope Mr. Musk builds his new banking system. The efficiency and low cost of such a system would be great. I hope he takes the path of using simple, non-fashion-driven tools and a grow-the-baby, post-hoc-design method to build his solution from birth through adolescence into full functioning adulthood. I look forward to it!
Comments