Over the last twenty years, Saas and Cloud have been the two emerging technology sectors.
Everything started with Saas. Salesforce went public 16 years ago, and many other companies have followed his example.
This business model relies on the idea of changing the purchasing model by eliminating licensing, installing, and other pain of traditional software.
Today the value of SaaS solutions exceeds $1.7 trillion.
Then public Cloud has risen after the launch of AWS by Amazon, Azure by Microsoft, and GCP by Google.
Many companies started building their software and business in Cloud.
Now a new emerging sector is growing: developer-driven software.
Unlike in the past that languished due to developers' inability to pay for expensive, "packaged" tools, these newer products are available online, often free, open-source, or at low cost, and shared widely across the global developer community.
Open-sourcing enables a community of developers to improve functionalities over time, providing public APIs and SDKs that make the product flexible to fit into many companies.
Developer-driven software
Every company is a technology company, no matter what product or service it provides. The companies that embrace this fact are the ones that shape our world.
Says Stephenie Stone, in "Why Every Company Is A Technology Company"
That's why developers are impacting more and more in the business model of a company.
From a tech point of view, the market of companies that aim to help power software development will grow significantly.
According to Evans Data Corporation, there were 26,4 million software developers in the world in 2019, a number that in 2023 is expected to grow to 27,7 million and 28.7 million in 2024. The USA is taking the leading position by the number of software developers reached 4,2 million.
With this increasing number of developers, every time you have to start building a business and thinking about a business model, you have to start thinking about developers.
But the problem is: how are companies supposed to generate millions in revenue selling to developers?
*Developers have not budgeted in a company to improve software development. *
They are looking for free or open-source software that can help them accomplish their goals.
The answer starts with winning the hearts and minds of developers before trying to sell them anything. If they adopt the product, they can contribute, use it, and spread it across the community.
So, how to generate revenue in this situation? Three business models have successfully appeared to commercialize developers love:
Let's analyze them better:
## Freemium
How does it work?
Freemium is a two-tiered user acquisition model, where a slight version of a product is available for free or in free-trial to help the adoption.
The main goal of this acquisition model is to decrease customer acquisition cost (CAC) for the product.
Freemium aims to create several loyal users and then transform them into paying customers as a next challenge.
Pros
- If many developers can try out the free part of the product, the opportunity arises to build a large, engaged customer base.
- Avoid overspending on paid marketing channels and focus more on building trust in the product.
Cons
- You have to convince the development team to a paid model.
- Competitors can copy the freemium version, but offering more for free, undercutting a well-thought-out revenue model.
Winning Example
Slack is a company that has fully exploited the benefits of a Freemium business model.
Slack started as a product "built by developers for developers."
The app's basic functionality has always been free, and only a part of the software comes in a paid solution.
Slack's win situation is that many Developers start using Slack and tell other colleagues and people in their communities, accelerating the product's flywheel.
But for sure, the difficult part is to get the flywheel spinning in the first place; developers still have to know the product and try it out.
API-based services
How does it work?
In most cases, APIs are the building block of a product.
The goal is to accomplish critical functionality commonly used by developers quickly and flexibly, so tasks such as payment processing or messaging.
The most critical problem for a developer is always time, with many pressured releases and strict specs to follow.
There are three different charge service fees commonly used:
- subscription fees (developers pay a monthly fee)
- consumption fees (developers pay a fee each time the API is called)
- transaction fees (developer pay a percentage of each purchase completed via API)
Pros
- APIs are flexible enough to cover most of the common cases that a developer needs. To do so, you have to listen closely to what they need and educate developers in forums, conferences, and virtual events.
- By integrating an API into a product, it will produce a stable stream revenue.
Cons
- Some developers can eventually decide to build their API to emulate the third party API into their products.
Winning Example
Stripe was created with the primary goal of making the implementation of payment systems easier.
Stripe makes it easier for everyone to make and receive payments. It allows developers to start creating and accepting payments by adding a few code lines to their product.
The leading cause of their success is that it offers a payment system simple, straight-forward, and easy to implement (and documented through the most well-written Docs I’ve read by far).
They focus on making the product developer-focused, and by doing so, they beat all other competitors.
The company's first funding was provided by Paul Graham, the founder of Y Combinator.
This seed of investment of $2 million helped to get the ball rolling on Stripe. The service became an immediate success. By 2014, Stripe was processing billions in transaction volume and present in over 12 countries.
Commercial Open-Source (COSS)
Last but not least, the most complex and intriguing one.
How does it work?
COSS is not a development-driven business model, but most of the code is written by the dev community while addressing to the dev community itself
In this business model, the core of the product is open and can be developed by anyone. Then only some premium features will be charged at the middle-enterprise level.
Many developer users may also contribute to an open-source product or other integration of it, making the core product more useful and valuable.
Frequently, the paid section of a product comprises enterprise features that include security and governance (such as SSO access to the product), collaboration, or high-availability.
Each company that is approaching this business model has a clear and transparent roadmap to all the community.
The trick is to provide useful functionality in the open core, so developers rally around the product, creating a groundswell of enthusiastic users.
Rarely do open source projects gain rapid user adoption on their own.
Expect that only because the project is on GitHub is gaining attention is not right.
Marketing, communication, and content have to be structurally changed from other business models.
Developers have to trust your project as the first thing. So you have to participate as many conferences as you can, host meetup, do technical conferences, communicate with other developers, and to respond to feedback on social media.
Pros
- Lower friction to developer adoption.
- Adoption rely on Word of Mouth, not conventional marketing
- If the open-source product gain attention, you don't have to take massive marketing at the enterprise level. Developers of the company will push themself to the adoption of the product.
- Create a virtuous cycle between technology innovation and business innovation. More people use the product means more feedback, that means more support to give, more premium feature, and so on. (We will talk about this in another article later)
Cons
- You have to manage to distinct Roadmap, one for the open product, and one for the close product. It is essential to be clear from the beginning
- The adoption is slower than a Close source product. So it is fundamental for the product to find someone that believes and invests in the project.
Winning example
Hashicorp is a company born in 2012 from an open-source project of Mitchell Hashimoto and Armon Dadgar.
And as he said: "We started the projects and never planned on making a company. It's totally fine that some people have ideas, and they do it to start a business, and that's normal."
Hashicorp bases his platform on the open-core product with specific enterprise features, with the goal to provision, secure, connect, and run any infrastructure for any application.
As Glenn Solomon says in "The Next $1 Trillion - Three Ways To Win Developers' Hearts And Minds" :
I invested in HashiCorp in 2014 and remembered the founders flying 250,000 miles a year back then just to visit developers at conferences, and spending thousands of hours working with them to gain insights from users about HashiCorp's early products.
This is exactly what is needed to gain popularity in an open-project.
Now the company is rising in the world of the Multi-Cloud:
Final Thoughts
Some months ago, a couple of friends and I started a long journey with an idea in mind: turning a project we strongly believed in into action.
Finally.
We sifted through many and many ideas trying to figure out which business model would be the best to support our rising product idea, intending to create something valuable and useful to help developers and companies to improve their work experience.
We came out with this and many other thoughts on which is the best sector and business model to be applied when you are working on creating a B2B product focused on Tech, and we are happy to share all this with you.
Are you starting your new product? Hope this can be the first step in your journey towards the success
Top comments (0)