TULSA: a new software licensing model for web3

It's difficult to argue with the fact that if you want to make more money for your business, you need more customers. The problem is that the bigger your business, the more problems you will encounter. Those are mainly rich people's problems, but still.

What if I told you that you can make more money while keeping a human-sized business, and all thanks to web3? This is what we are going to reveal to you in this article, but let's start with a bit of history.

Do you remember the first software you bought? Well, depending on when you were born and when you first started using a computer, the answer will be very different. That's right, the way we license software changed a lot since we first sold a piece of software, about half a century ago.

In the beginning, software was not even a commercial good. It was plainly shared for free or distributed bundled with sold hardware, as part of the service to make the hardware usable for the customer.

Then, due to changes in the computer industry in the 1970s, software slowly became a commercial good by itself. That's when we started talking about packaged software–software that was neither produced as a one-off for an individual customer nor bundled with computer hardware.

At first, it was in a physical form, starting with floppy discs that you had to buy in specialized shops or that were mailed to you. The CD-ROM, a Compact Disc that was able to hold any form of binary data (and not only music) was introduced by Sony and Philips in 1985. It quickly became the new standard for storing software and remained dominant until the end of the 90s. Then, in the 2000s, with the democratization of high-speed Internet connections, it became possible to get your software directly from the web. There was no longer any need to get physical (at least for software).

The pricing model at the time was very simple, either if you bought your software in a physical form or not: you just had to pay once and the software was yours. If you wanted an upgrade, you had to wait for the next version, sometimes for many months (or even years), which meant buying an extra physical disc or downloading an extra executable file (and usually paying for it).

For example, if you wanted to stay up to date with your encyclopedia, you had to buy a new version of Microsoft Encarta every year. And it was not cheap at $99 per unit. It's very difficult to imagine that these days, with a free online encyclopedia like Wikipedia being much more complete than Encarta ever was, and seeing thousands of updates every hour of the day and night.

Let's fast forward to about a decade later. With the rapid evolution of the web platform, especially with the specification for the XMLHttpRequest object (circa 2006) and the apparition of JavaScript frameworks like Backbone, Angular, React, and Vue (from 2010 until now), it slowly became possible to run sophisticated applications in the browser.

These applications, hosted in the cloud, require an Internet connexion to run (even if some can run offline), but the big advantage is that you don't need to do complex upgrades anymore: you refresh the page in your browser and you are automatically on the latest version.

Nevertheless, as a software creator and maintainer, things are a bit more complicated to manage. It used to be only about building the software once and selling a multitude of copies, the more the better. With current web applications, it is different. Applications run on remote servers and you need to make sure that they are always running smoothly and apply server upgrades when it’s needed. If your app uses different technologies like Node.js, RabbitMQ, Redis, PostgreSQL, or ElasticSearch, you also need to make sure that every single one is up to date, and that everything works well together. It's not a trivial job at all and most tech companies now have dedicated teams to take care of that.

It’s not sustainable anymore to offer to pay for the software once, as it will not cover the recurring costs to run and maintain the servers and the software itself. That’s why a new model emerged, which consists in paying a recurring fee (monthly or yearly) to have access to a web application. This model is called SaaS, for Software as a Service.

This model has been dominating the market for more than a decade now, with a lot of new unicorns being SaaS companies (Canva, Figma, Airtable, Miro, Notion, Slack, to name a few), but it's slowly showing its limits. If you want to make more money with a SaaS, you need more customers, which will increase the traffic and thus the costs to maintain your servers. When you get bigger you also get more exposed to technical failure and you become a potential target for hackers. And this is just the technical side of things. More customers also mean more support, and this can also quickly get overwhelming. If you want to acquire more customers and serve your increasing number of customers better, you also need to hire more people. Many more people. At the end of the day, your job as a successful SaaS company will be more about keeping the service up and running and making sure all the stakeholders (investors, customers, and employees) stay happy than really innovating. If the growth is fast (what many founders are pushed to achieve), it's even harder to keep up.

Have you ever felt that a product you loved when you first discovered it a while ago deteriorated the more it became commercially successful? Yes, me too, but it doesn’t have to be this way.

What if there was a model where you could make more money without having to get more people on board? Well, this is what TULSA is about, and it’s made possible by web3 technologies, especially non-fungible tokens (NFTs).

TULSA stands for Token-UnLockable Software Application and its main principle is that it allows you to limit the number of users you have on your application at any given time. How? By only allowing people owning a token (an NFT for example) to access your application.

Imagine you feel comfortable having 1,000 users for your application. You just have to generate a collection of 1,000 NFTs and only allow holders to access your application. If you’re providing a good product, people will be more and more interested in it and the token price will increase on the secondary market. The royalties on the resale of the tokens will assure money running to you on a regular basis. And if you feel that you can handle more than 1,000 after all, you can always start another collection.

There are many good side effects to this. First of all, your early users will be rewarded and actually make money thanks to you, by reselling their extra tokens (or all of them, if that’s what they want). They will also be ambassadors of your product because it’s in their best interest if your product is getting traction, the value of their token will increase.

Also, in addition to generating revenue for your product, every time you launch a new collection it can actually be seen as fundraising. And with traction, you’ll raise more and more each time. You could realistically stop being dependent on VCs to grow your business if that's what you want.

You will generate a continuous revenue flow by improving your product and getting royalties on resales, all while having a limited user base to take care of, assuring that you can serve everyone in an optimal way.

That's what we want to do at 0x3 Studio with our JellyBots NFT collection (which will go on sale very soon). And we are not alone. Some other companies have already started experimenting with this idea, like Disk Drill, a data recovery software, or Spendee, a money manager and budget planner. Still, we are really at the very beginning.

In our opinion, this is a great alternative model for the future. Not all entrepreneurs want hypergrowth anymore. Some people just want to make a great living and have a balanced entrepreneurial life without having the ambition and undergo the hustle to build the next big thing. This is now easier to do than before, thanks to web3 technologies. The nice bonus is that it gives utility to NFTs along the way, which we must admit are often sorely lacking. We just killed two birds with one stone.