Earning the right



When Splits debuted, it did only one thing: distribute ETH on mainnet. But it did that well. People's eyes lit up, and they wanted more. So we added more: support for all tokens, the ability to edit Splits after creation, and additional networks (an ever-growing list). Today all three of those things — ERC20s, mutability, and L2s — have greater usage than ETH on mainnet.
It's easy to see how this would be the case in hindsight, but in late 2021/early 2022 most NFTs were on mainnet, Base hadn't launched, and stablecoin adoption was nascent. When you're in the moment, you don't have the benefit of hindsight, so the only path forward is through.
We picked up the concept of "earning the right" from a friend several years ago, and the framing stuck, since it applies broadly. Builders want to build, and unfortunately it's all too easy to build things that nobody cares about. Tomorrow is not a given, and we only get there with the correct choices today.
Sequencing as strategy
What you learn today affects what you will do tomorrow. But if you're already tackling tomorrow's problem today, you don't have the information to solve it properly.
We didn't integrate swaps into Teams immediately. It felt obvious that we should include swaps, but when to prioritize it was not obvious. What was obvious, however, is that swaps are only needed if you have assets to swap. So we built swaps only after we, and other users, became annoyed by constantly connecting to third party apps to swap. At that point, it made sense to "pave the cow path."1
Swaps are now a highly used feature, and they've unlocked other features like just-in-time asset transfers, which couldn't exist without swaps.
Every decision creates the foundation for the next one. Shortcuts often become technical or cultural debt. Some sequences unlock exponential progress, while others brew headaches.
Engineers want to build elegant solutions. But customers don't care about solutions, they care about problems. Rather than picking between the next dozen "obvious" features to ship, we try to figure out which of our customers' problems are most immediate and painful.
Commitment engineering
One tool that works for us when taking on larger initiatives is commitment engineering. It helps us validate demand and find early adopters instead of just hoping they appear.
Before building anything significant, we ask potential users to commit alongside us. The promise is usually informal and commensurate with the investment we're making. "If we build something that does X, will you get on a 30-minute call with us to understand your needs, commit to using our MVP, and provide ongoing feedback for iteration?" For a new Teams feature, that's enough to be a meaningful signal, especially when multiple customers are willing to do it. You would be surprised how many feature requests disappear when you ask users to commit their own time and resources to the solution.
We wish we had adopted this approach sooner. A few years ago, we observed people manually editing Split contracts after processing a certain amount of funds. When we asked about it, we learned users did this to repay one group before paying another (i.e. recoup expenses). We also knew this approach is widely used in traditional finance — venture capital funds work this way, as do preference stacks and debt more broadly. So we built Waterfall.
The result? Very little usage. As it turned out, users were mostly satisfied with mutable Splits. They didn't consider Waterfall's extra setup complexity to be worth the effort. We rushed into a solution without asking the right questions first.
A balancing act
It is tempting to double the team tomorrow and tackle mobile, fundraising, privacy, invoicing, credit cards — never mind improving critical infrastructure around indexing, spam, pricing, and notifications. There's an endless list of requests to fulfill, which is a luxury we've earned.
Building a startup means accepting that you'll always want to do more than you can do well. That tension is a compass pointing toward the next step to be earned. The challenge is balancing two extremes: being so judicious that you miss the window to ship something that matters, versus being so reactive that you lack strategic direction.
At a certain point, "You have to be ahead of the curve and take that risk," as Rish from Neynar put it. "That's your comparative belief advantage."
This is where our 10-year narratives become crucial. Principles like "people will always want to earn more money" or "teams need to share resources" provide strategic consistency while tactical decisions remain flexible. Reliable principles give long-term direction, while commitment engineering lets us tack toward that vision in the short term. Both are needed for long-term success.
1 "Paving the cow path" is another term that's stuck with us. If you need a road through the wilderness, don't just dive into the brush with a machete. Instead, look for the rustic, rudimentary path that is already being used, and start there. ("Desire path" is a related concept.)
While we've got you here...
At Splits we're building institutional-grade banking that's instantly available to everyone in the world. Built on Ethereum. No account minimums, paperwork, or legal entity needed. Sign up today.