Unbunded Startup. Image by Juan Pablo Bravo from the Noun Project
Company formation, though augmented, is largely the same as it has been since the inception of venture capitalism.
Generally it goes like this:
A single person, or small group has an idea, builds something. Whether slide-ware, or an MVP, the team shows they can execute on it. They try to get some traction to show people want this product. They walk up and down Sand Hill Road until a check falls into their hands, while simultaneously shaking down family and friends. Substitute the Silicon Valley hike for an accelerator, incubator, or a few other options. Once there is a modicum of traction and an MVP, and given they’ve been able to sell their story, the team hires. Let’s take a traditional SAAS app. This team is expected to be able to execute on the front end, the back end, sales, marketing, fundraising, accounting. How about a blockchain company? It’s SAAS + cryptography, smart contracts, distributed computing. More areas the company must become an expert in. A monumental task.
This, however, has worked. Every unicorn today comes from a slight variant of this story. But what if there was a different way to approach the same outcome?
What are the outcomes, generally speaking?
- impact
- solve a problem
- return for investors / creators / participants
- a fun journey?
- (an exit)
That last one is relatively new. People form companies today thinking who they’re going to exit to. This wasn’t always the case. Early internet companies had no notion of an acquisition. They built companies they hoped would continue to grow to the size of Fortune 500s. This is a very different mindset than today. I met two young entrepreneurs at a Meetup I host who had built a small computer vision app whose tech they hoped would be an acquisition target for Google. What about bringing value to people, or solving a real problem in the world?
“There are two ways to make money in technology. Bundling and unbundling.”
Decentralization + Unbundling
I want to work through two examples of how an unbundled startup could work. Keep in mind that one major difference between the current approach and the unbundled approach is that each of the projects built in this manner could outlast the team that created them. If a smart contract is involved, in 30 years someone could still run an Ethereum node and use it.
Unbundling a Dapp
Theoretically, you could create a new front end for crypto kitties, charge a fee and forward the rest of the functions to the original crypto kitties smart contract. You could build your own company on top of the work they’ve already done adding your flavor or style adding some kind of value. Whether that value is a set of new assets, or just a different UX, you don’t have to be an expert in smart contracts, back end scalability, or database administration to do so. You just have to know how to build a front end and a little bit of an api to interact with a contract. If you already know how to make front ends, you could learn that second part in an afternoon. I expect to see more experiments in this space in 2018, hopefully beyond CryptoKitties.
What are the implications for this? One that comes to mind is that backend devs or smart contract devs have more power guiding the possibilities of front ends. They set the rules so to speak, they confine the scope… initially. Another version of this story would stack the smart contracts adding new functionality, or subtracting functionality, enabling other front end possibilities. The same could be said for backend. One example would be a layer on top of 0x to create a better, canonical way to save and match decentralized exchange orders. In that world, you could enable other developers to come in and participate by building the pieces you don’t know how to, or don’t want to, and reward them for it by offering a mechanism of compensation, likely in the smart contract. A user coming from one front end sticks an identifier in the signed transaction that the smart contract can then parse and reward, or act accordingly.
Unbundling a company
What if a company went vertical in their team’s capabilities?
Let’s take a fictional company BetterCenter. They reduce the cost of running a data center by some software layer that controls the HVAC system. This team would normally consist of a team of sales, developers, marketers, C-Suite, etc. Instead, they took all those resources and just invested in finding 5 amazing embedded systems devrlopers and wrote the code to lower data center cooling costs by 50%.
So the core of the product is ready, but they don’t know anyone in the HVAC industry. Instead of hiring a BD guy full time that already has those connections, why not incentivize someone already in that industry to take equity in the company and try to leverage the people he / she already knows to sell. This isn’t so different from the real world today, though the implications of doing this throughout the company I think are fundamentally different.
Though the ‘hard part’ of the dev work is done, there is no front end. People need some kind of way to interact with the system, but BetterCenter only has embedded engineers who don’t know the first thing about either the U or the X in UX.
Instead of hiring front end developers, BetterCenter incentivizes the creation of the front end through equity, or revenue share in the project.
They do the same for the backend.
And for marketing.
But isn’t this just outsourcing?
In a way, yes, but i think there’s something fundamentally different about organizational structures built around this concept. That individual or team of front end developers could float between different projects, earning equity each time. They could brand themselves as the go-to front end team. The could do this with or without the permission of the original team, perhaps if the code is open source, or the smart contract interface is known.
A team of BD experts who are already well connected in a vertical could negotiate excellent commissions and sell order of magnitudes faster than a team could trying to penetrate the industry or organization for the first time.
I think the distribution of equity and payout would be more fair in this world. The founders wouldn’t have to raise as much capital, and would be less beholden to the power of whomever they took money from. Perhaps this could all be bootstrapped. Contributors would be able to participate in revenue they helped generate. Even the notion of a founder changes. Though there is a chicken and egg problem we already see some inklings of the possible future with sites like CodeCanyon and the Envato Marketplace, or even wordpress. There are thousands of plugins, reusable code, generic front ends that enable the rapid development of all kinds of products. The same thing is happening for smart contracts and back ends. I don’t think there is an implicit sequence in this story, it just flows better that way because that’s one of the only ways we’ve seen it play out.
This doesn’t just confine itself to companies. What about a song, or a band, or a film script, or a book? They would all utilize some kind of base operating principals. Perhaps there is a software layer to facilitate that process.
To a large extent this thinking has been confined to a Zero to One problem. How to start. But as the organization grows, perhaps even crystalizes, there are a gamut of options with this kind of foundation.
Optionality is paramount.