Urbit's true market opportunity goes beyond social computing

For Urbit to succeed in being the 100-year computer, it cannot solely focus on decentralized social computing experiences such as private group chats and crypto-multisig applications. It must become a high-leverage tool for the small organizations, dynamic teams, and high-output individuals (who will likely grow out of these social computing experiences) to coordinate and exert their wills to shape the world around them.

Urbit's success will feed and be fed by a flywheel that massively grows the market for custom software, increasing the carrying capacity of the ecosystem (and the demand) for boutique software agencies who service multiple clients. This will be possible thanks to a technology stack that provides a reduced cost of custom networked applications, paired with a longer time horizon for investment payoff.

This future is not guaranteed, and to achieve success it is important to frame the landscape correctly.

Urbit's Big Promises

As it pertains to Urbit becoming a high-leverage tool, Urbit's biggest promises are those of low-maintenance, and permanence. As I'll cover further into this piece, these two elements will create economic realities that will upend the way that businesses and individuals build the systems which support their missions and passions. These promises must be supported by a variety of deeply technical realities, but it is important for the people responsible to implement the technical realities to not lose the forest for the trees. In trying to make Urbit 'diamond perfect', we need to be careful to not make it as useless as a diamond. Or cactus.

That said, the people working on the current technical problems have a stronger pathway than ever (see more at https://roadmap.urbit.org) and aside from a timeline risk for specific organizations at present, there are some more general challenges that the urbit ecosystem needs to face. And for which I will make the case that enabling individual and small teams of developers is a core element of broader success.

Current Ecosystem Challenges

Urbit Works. This should not be understated, but for technically-inclined developers and early adopters it can be easy to miss the forest for the trees and forget that it needs to work for something useful.

Aside from the general macro environment, and the execution of technical roadmap initiatives, the Urbit network has a few more high-level challenges to clear in order to have a chance at long term success. Broadly speaking, these challenges fall into three categories: Developer Adoption, User Growth and Revenue Generation. In a world where the macro environment were super friendly and a more traditional tech stack was being utilized, a platform play would likely address these challenges in exactly this order. But due to the nature of Urbit--namely in it's role as a simple to run personal server on which you run your own networked applications--I will make the case that we should address these in reverse order.

Revenue Generation

In the traditional web2 stack for digital social experiences, users expect to basically use free products that probably spy on you and steal your data—but they don't really care because free. And unless you care about privacy or sovereignty, these experiences are pretty good: they're fast, there are lots of people in the network, they are populated with gripping content. Did I mention, they are free?

To pull people away from such an experience, to top the competition and make the switching cost worth it, you need to be 10x better, right? Given the billions of dollars that have gone into user research, UX studies, addictive UIs, etc. Urbit's plays at digital social experiences have a very long uphill battle towards adoption, let alone monetization.

In a pathway where user growth is the first challenge to tackle, viral social experiences are great because they bring in ever more users into the network. But with revenue being fairly pinned at, or at least asymptotically approaching, zero in social experiences, the should not be depended on for monetization. Not to mention, the Customer Lifetime Value (CLV) of social app users is small, particularly when advertising (attention hijacking) is not the revenue model. Similarly, freemium is great for user growth, and not all users need to be monetized as long as the additional premium offerings are truly high leverage and free users offer a sufficient pipeline such that customer acquisition cost (CAC) is manageable (perhaps because of the presence of a large VC warchest and the known/very-low per-user costs of the traditional stack).

But if you want to get to revenue generation on the urbit stack (which you should, because even for revenue models that depend on scale, you need to prove to VCs that it is possible to earn anything at all building software on urbit—no, hosting doesn't count.), competing in an already highly saturated market is going to take you to hell in a hand basket.

To pile onto the novel revenue generation challenge of a new platform, the nature of Urbit applications running as open source software means that you get many of those same challenges of other open source projects:

While Urbit's vision promises to address the ever growing complexity problem, it also must address the other challenges to revenue if it wants to succeed in the long run.

User Growth

(A note: Since this piece was originally published, user growth has started to grow tremendously thanks to work from Tlon's free hosting, ChorusOne and Uqbar's mobile onboarding flow , and Holium's Realm + Third.Earth efforts; check out https://network.urbit.org for the latest stats)

Aside from online users being negative over the last 3 months, there is a secondary pain point to user adoption which seems to be that nobody is actually paying attention to it.
image.png
image.png
There has been some base level assumption that 'someone else has got it covered', or 'we have really high value users'. And while these assumptions are somewhat grounded in a loose reality, i.e. "hosting is still being worked on," and "Balaji said our killer app is our community," there is far too much resting on laurels being done (whether for sake of urbit's purity or otherwise). Let's give this the benefit of the doubt and say both third.earth and tlon.network have live hosting products that are just pending a push to be fully scalable. Fine. Let's say we do have a super high value community. Great. Now let's make that community more powerful with tools that they can't get anywhere else.

Instead of focusing user growth on viral digital social experiences, focus on finding customers that will pay for a unique experience or tool that makes them more effective in their outside life. For whom Urbit and urbit applications are not just a fun consumptive good, but an investment that makes them into higher-leverage operators. This market is smaller than the total set of 'users' but has a much higher CLV (think, Annual iPhone purchaser, vs daily Twitter user), and it is likely that these org and individuals will become the core funders of urbit application development, or potentially heavy hitters in future contributions to core development.

Developer Adoption

This challenge is probably the one that is currently being addressed most directly and successfully, but only for a certain definition of developer adoption . If narrowly defined as 'a decent number of devs are learning urbit development and enjoy doing it', then urbit is crushing it. But where the flywheel is lacking is in developers being able learn urbit development and then start making money; particularly when compared to running down a python+ML library route or other legacy stacks. Really this goes back to having a proven pathway to revenue generation, such that developers wanting to work on urbit dev are not directly dependent on the macro investing environment, VCs funding urbit companies , or some random crypto-riches from their past undertakings (which defacto just makes urbit a passion project, rather than a fundamentally useful platform). What Urbit needs is something akin to a 'partner channel'; organizations which can directly benefit from bringing the platform to outsiders and building solutions atop it which result in real, unique value for the outsiders.

Urbit's current solution

The general assumption at present is that the orgs working on core development are large holders of address space, which will presumably be saleable and able to fund development to the point of external value generation for some audience. While this may be true for getting the runtime and the kernel work through the current roadmap, those endeavors should be correctly thought of as foundation building, and perhaps not even revenue dependent.

And as it comes to uptake in the market, User Adoption and Developer Adoption are somewhat conflated on the level of the individual consumer and ignored on the level of the productive entity.

Shortcomings

With social activities being largely 'consumptive' spending in the grand context of life, the ceiling for revenue generation—particularly in the current macro environment—is capped. If you think of Urbit writ large as a network state, it needs to be able to export something of value to generate the resource to import the products/services/assets which it cannot produce itself.

Similarly, dependency on outside solutions for productive work, and lacking material means of revenue generation, leads development is purely funded by asset sales rather than being able to be bootstrapped from pure value generation for outsiders. While asset sales or equity raises may be appropriate for early stage or highly capital intensive enterprises, Urbit application development has even fewer capital expenses than traditional SaaS (i.e. no server farms to run) and so should be focusing instead on how to leverage those assets in order to extract revenues from the outside world.

Looking at the Outside World

The outside world is not merely a resource farm for Urbit, but also should be studied for lessons in building technology solutions that people use and pay for—and that they can't yet afford but greatly desire.

What do people actually want to pay for?

When the compensation for the tech stack is separate from the user experience (as it often is in open source environments), it is hard to extract the rents necessary for funding the tech stack (i.e. the bits and pieces that end users don't see or understand). But it is certainly not impossible, and there are models to follow. Namely, that of Systems Integrators. Red Hat is a possible example here, but instead of focusing on 1:1 corollaries in web2, I instead want to pivot to focusing on the concept that people will pay to exert their will on the world. SaaS tools call this 'Solutions' on their websites, UX designers talk about 'fixing pain points', Systems integrators call these 'Custom Implementations', etc. but at it's core it is about enabling your customers to have the world be the way they want it.

For any individual, or collection of individuals, a common way of implementing one's will in a directed fashion is to start a business. In the modern age, that business will inevitably include some set of software tools which will require some balance of capex and opex costs which go into building their business logic, executing production efforts, and running their operations, and then the organization will have an expectation about a return on that investment.

To solve problems for this audience is to solve the revenue generation problem. Why? Because if you can save them time/money/hassle (instead of consume it, as social apps do), you make their directly more capable of paying you for your efforts. Now, this business model has been proven in the United States time and time again. For example, with a ~$300B systems integrator market in 2020 alone, projected to grow to ~$1T by 2023 (~13% CAGR YoY). This compared to an ERP software marketing of only ~$40B in software sales revenue in 2020.

The actual market is one of custom integration services delivered on top of much smaller revenue base consisting of an increasingly complex tech / business application stack. The long tail of services revenues absolutely dwarfs the initial software sale. In an environment where much of the base software is expected to be given away for free (or otherwise freely acquired), it is this long tail that offers the opportunity for revenue growth (vs asset value growth, i.e. of Urbit Stars).

To harken back to Urbit's big promises, if urbit can truly change the maintenance and permanence calculations for investing in custom software, it will drastically change the 'area under the curve' for the supply/demand graph of 'Custom Business Software Implementations'.

Who wants to give us their money?

Urbit obviously wouldn't go after the SAP, Salesforce, and Microsofts of the world. The point is not to try to challenge enterprise solutions head on, but rather to take inspiration from what successful, well-capitalized, large enterprises have done as they have grown and apply it in the context of Urbit to solve the Revenue, User, and Developer challenges.
Instead, we should aim at a tangential audience which has unique, targeted pain points that are too costly to serve with the current stack (aka web2 ball of mud): Small and Medium size Businesses (SMBs). And their pain points are acute.

"Software-as-totally-not-a-service"

At first glance, particularly to those coming from a perspective where Urbit is competing with 'SaaS products', this approach screams 'not scalable' or 'too small a potential userbase'. But let's take a look at how software exists in the outside world for business owners:

  1. Buy SaaS Solution, it does 80% of what you need.
  2. Buy another SaaS Solution, it does the next 10% of what you need.
  3. Repeat 10+ times until you get nightly migranes and reach 95% effectiveness in your SaaS stack. Realize you are spending all your time getting the system to run instead of outputting the thing your system is designed to help with.
  4. Hire someone to do this for you (if you can afford it, otherwise struggle through it yourself).
  5. Get to 100% for your system.
  6. A random SaaS tool your company relies on has the provider get acquired and the new owner changes your subscription and turns off your most important API connection.

Well that is quite the nightmare, isn't it?

As for market size, if Urbit development shops were able to sell an average of $100/mo in services to the currently underserved 30M small businesses in the US alone, that would be be a comparable market to all current ERP software sales. Oh and 10x the revenue of Twitter (~$4B in 2020).

For many small businesses, "Software-as-a-Service" came with an implied promise that you would buy the software and headache of ongoing maintenance and access and all the other PITA elements of running your own software would go away. Except what really got trojan-horsed into our businesses and lives was "Software-you-don't-own-and-which-will-still-be-a-huge-headache-to-run-and-integrate-with-the-rest-of-your-system". And only if you had enough money did you get to pay extra for services that would make that software do exactly what you wanted it to do. But with Systems Integration projects from consulting firms costing in the hundred of thousands of dollars, potentially taking years, and having an extremely high failure rate, for most organizations they just aren't tenable.

Focusing on the underserved

This audience should also appropriately be segmented into a target market of "Small orgs building digital products" and "Small orgs delivering digital services" and a secondary market of "Small orgs doing meatspace things". Certainly all three should be further studied to understand where Urbit adoption is likely to make the biggest impact, but for the time being we will take the assumption that there are two likely pathways with this segment:

Existing Urbiters with Existing Services Business

Existing Urbiters don't need to be convinced that Urbit is a good long term play, and value alignment is likely to be high, so the urgency here is to make Urbit immediately useful to these individuals and small teams. Group chats are the start of this, but additional layers of business tooling and very high-leverage custom integrations are necessary to prove out that Urbit can be a high-leverage tool. Crypto integrations and digital reputation implementations are likely a strong place to start. Finding a target customer and building an urbit-native version of their workflow to boost productivity is a valuable endeavor here.

Digital Product Startups looking for a competitive edge

Startups and hype in the web3 space appear to largely be rehashes of web2 services but 'with tokens and community and whatever other bs VCs will buy'. How many different versions of microblogging and dropshipping can the web2 stack support? Who knows. But a new technical stack offers the chance at new 10-100x breakthroughs. The broader ecosystem should support Urbit developers in pitching startups to build their companies on (or at least including) an urbit tech stack. This isn't to say 'we need more urbit companies that will look for funding from urbiters', but rather, 'urbit developers should sell their services to entrepreneurs wanting to build truly novel product experiences'. Holium, Vienna Hypertext, and Column start to allude to this, but small development shops like Quartus should take on customers along these lines, help them build an initial urbit development practice, and help feed talent coming out of the Urbit Foundation developer education program into projects that are funded not for 'being on urbit' but for 'being valuable products that are only possible because they are built on urbit'.

What does this look like in the end?

This piece aims to presents something along the lines of an opportunity analysis rather than a prescribed hardline solution to the Urbit Ecosystem's challenges, but I will take a swag at possible visions for the future. With user and customer needs being addressed on a much smaller scale with much more personalized service, the traditional web2 SaaS Product market—and accompanying organizational structure—will experience a bit of a jolt. The base case is that the models seen in enterprise software (channel partners, consulting firms, design agencies, etc) will occur at a smaller scale and provide services just to the upper end of the market with a lower floor.

But the real question is if the floor gets low enough, and social communities can get bonded or cohesive enough, that software production can break out of the silos of Business-to-Business (B2B) and Business-to-Consumer (B2C), into something akin to 'Network-to-Community' (N2C). This model might include anything along the lines of the following:

All in all, what this *should *look like is a blurring of the line or stretching of the spectrum between scalable and custom software. And if we assume that core development will succeed, supporting this future needs to be an important next step in long term Urbit success.

What ought we support?

While the above thesis offers a vision for enabling developers to capture revenue in this market structure, open questions remain about how to support the middle stage of the journey. This probably requires explicit support/action on the following:

Bringing it home.

To harken back to ~ravmel-ropdyl's analogies around homebuilding, modern SaaS currently supports the peons living in a Motel Six (You better just accept your cigarette smoke-saturated curtains), and the Billionaire with the custom-sized hot tub and Cessna hanger. If Urbit wants to support the vision of technology spaces where you might build your own tools, or someone else might build it for you, or you might hire someone to help with some technical elements while you craft the specific vision, it will need to support a system of general contractors, architects, electricians, drywallers, and the home workshops that anyone can call up, get a quote, and (relatively) easily hire to iteratively improve your space.