February 10, 2021

Sdkbin February 2021 Update: Revenue, Results, and Roadmap

We launched Sdkbin, our NuGet meets App Store marketplace for .NET developers on September 30th 2020, but with an important limitation: that Petabridge would be the only publisher on the marketplace until we had a chance to eat our own dogfood and work out functionality / user experience / business process issues with our customers first.

You can read the full launch announcement here.

I wanted to provide an update on how things have been going, what our progress with Sdkbin looks like, and what we’re currently working on.

Sdkbin - the marketplace for developers

Actual OSS Revenue

The only product we’re selling through Sdkbin right now is Phobos, Petabridge’s application performance monitoring library for Akka.NET.

We originally launched Phobos in August, 2018 and we struggled to find traction with it. We tried to follow what other enterprise / business-to-business open source businesses with clientele similar to ours did and introduce per-node licensing that scales up in cost with the size of our customers’ installations. Small enterprises would pay a nominal amount, big enterprises would pay a lot more.

Unfortunately, that model was a really poor fit for our business. We had a lot of customers who wanted Phobos’ telemetry for their Akka.NET applications but the pricing scheme made it impossible for customers to predict what they might spend on Phobos without having to talk to us.

Having spent the better part of 6 years learning how to work with procurement departments that run the gamut from the United States Office of Personnel Management, defense contractors, hedge funds, state courts, foreign governments, video game developers, publicly traded companies, and early stage startups - if there is one thing I’ve learned it’s to make your value and your pricing understandable to the people who run the purchasing and procurement process.

So in preparation for going live with Phobos on Sdkbin in summer 2020 we significantly changed Phobos’ price structure in June, 2020:

Strategically we decided to risk making less revenue per-customer in order to make up the difference on volume.

We launched Sdkbin on September 30th, 2020 - and since then we’ve been selling ~50% more Phobos licenses per month beyond what we were doing before with no marketing. The ease of being able to purchase the license without having to talk to a human being first and the accessing the product instantly made a key difference to the experience of our customers. You can see what Phobos’ listing on Sdkbin looks like for yourself here.

It wasn’t until December 15th, 2020 that we even announced Phobos 1.0 and its new pricing - even though both of those products / pricing had been in effect since June.

As of late January 2021 - we’ve started doing some more serious marketing around Phobos and we expect that we’ll be able to grow the number of new purchases per month to 2x-3x their current levels.

Recurring Revenue

Let’s say you’re selling $4,000 to $12,000 per month in product sales. That’s a great start but you have to remember - these are recurring licenses that renew once every 12 months. The trick to making this type software licensing business sustainable is efficiently growing your new sales while getting your previous years’ customers to renew at high rates. This has the impact of compounding your marketing and sales efforts from previous years.

If we assume the following variables, a fictional example using Phobos’ pricing model:

Year Revenue
1 $48,000
2 $84,000
3 $112,000
4 $136,000

N.B. I rounded down the number of retained customers each year, to be conservative.

A well-run business would obviously have to figure out how to scale beyond 1 new sale per month, as that’s the input that is going to determine how much your revenue growth compounds annually. But even without that crucial element you can see and appreciate the compounded growth of recurring revenue models. This is what we’re trying to help ourselves and everyone else achieve with Sdkbin.

Results

So we shared the revenue numbers - but what about the engineering effort on Sdkbin itself?

We spent most of October through December stamping out bugs in our multi-tenancy system, email notifications, content management, and onboarding Petabridge’s pre-Sdkbin Phobos customers onto the platform - an experience which made clear to us the need for numerous (completed) UX/UI fixes and authoring extensive customer-facing documentation on how Sdkbin’s onboarding, access, and payment systems work.

In January we released an initial version of a feature I’ve been wanting ever since we launched Phobos: customer-specific NuGet installation statistics. We can now see which customers are actually using the products they buy, something that was not at all possible with our pre-Sdkbin solution.

Why is this important? Because it tells us well in advance which customers may not renew their subscriptions - customers who are frequently using and getting value out of your products and services are the ones who are most likely to renew. It’s the customers who infrequently or never use your products and services that you have to worry about.

And this brings me to the Sdkbin future roadmap.

Roadmap

So what are we working on right now for Sdkbin?

Automating and Improving Retention

Given how crucial customer retention is in the math of building a recurring revenue businesses for software developers, this is our current focus: automating the renewal process through Sdkbin.

There are several factors that can influence a company’s decision not to renew a subscription:

  1. Turnover - the key person who knew about / authorized / actually used the subscription leaves the customer organization.
  2. Lack of Value - not enough people used the product or service, so it was cut from the budget to make room for something else.
  3. Lack of Awareness - an even worse version of the “Lack of Value” problem, where in this instance people would have used the product or service if they knew it existed and their company paid for it.
  4. Chose an Alternative - the customer decided not to use your product or service any longer and you didn’t find out about it until it was time to renew.

Did you know that all of these problems are fixable? This is what we’re trying to accomplish through Sdkbin.

The Turnover and Awareness Problems

The Turnover and Awareness problems have the same cause: not enough interfacing and interaction with all of the stakeholders in a customer organization. Because there’s a small number of human contacts involved with a purchase and, possibly, with direct consumption of the product or service - all it takes is a small number of people leaving the company to eradicate the utility of the original purchase.

To solve this problem Sdkbin uses a multi-tenancy model that makes it easy for organization and team owners to invite all of the other team members to access the products and services they consume through Sdkbin. Some of these other users who are invited to a company’s Sdkbin organization can, in turn, be given permission to process renewals or invite other users at lower permission levels.

This mitigates the Turnover and Awareness issues by spreading the knowledge, access, and communication out to a larger group of users - many of whom are the individual contributors who will be consuming the product every day.

During renewal periods, the Sdkbin platform will automatically contact users who have “purchasing power” to ensure that a billing method is added, to make them aware in advance that a renewal is coming, and to alert them in case there are any changes to their subscription they need to be aware of (i.e. pricing, license changes.) In the event that none of the users with purchasing power respond and the subscription looks like it’s going to lapse - Sdkbin begins emailing ALL of the users on the subscription regardless of permission level to let them know that they’re at risk of losing access to their product or service. If any of those users reply, the reply will be sent back directly to the publisher - who can help them ensure that their renewal goes through smoothly.

This automation replaces a massive amount manual work our sales teams have to do today; scheduling meetings, combing through LinkedIn, trying to paint a picture of what a customers’ organization chart looks like from the outside. And this is relatively low-hanging fruit as it helps customers realize value from their subscriptions by socializing access to them AND it helps the publisher figure out who to contact when turnover inevitably occurs.

Lack of Value and Alternatives

If your product isn’t delivering for customers they’re going to go with something else. The easiest way for you to tell is by measuring your customers’ usage of your product - low usage == low value.

Since we added product analytics for publishers to Sdkbin earlier in January, it’s been invaluable for us - myself and our operations team have been manually reaching out to customers with low download counts to see what’s up.

We learned about performance problems with Phobos, documentation / installation issues, and about missing functionality our customers wanted. Since then we’ve made lots of updates, improved documentation, and are routinely working on improving performance.

Improving the value of your products requires gathering negative feedback from customers - as that’s the only kind of feedback that is actionable. If you don’t do this, customers will silently seek out alternatives and not renew.

Thus, one of the other issues we’re working with Sdkbin is periodically nudging customers who are “inactive” - checking in on them with customizable emails, surveys, and other tools we can use to help automate the feedback-gathering process in order to make sure your products are getting the job done. This work is most effective when it’s done early in the customer lifecycle - not two weeks before a renewal.

Wrap Up

All in all, what we’re trying to achieve in the current sprint is really a type of data-driven sales automation - work that most software developers likely do not enjoy and is extremely labor-intensive when done manually. But with a platform like Sdkbin these tasks can be performed intelligently and in a targeted fashion that is specific to each customer account.

We’re dogfooding this with Petabridge’s own products right now with the aim of quantifying our retention and renewal outcome numbers as social proof to other developers who will want to explore the Sdkbin platform for their own businesses in the future.

So far things have been very successful for us - but we have many more UX and feature improvements yet to come that are critical to ensuring smooth operations for everyone on our platform including ourselves.

Please let us know if you have any questions in the comments or you can contact the Sdkbin team here.

Discussion, links, and tweets

I'm the CTO and founder of Petabridge, where I'm making distributed programming for .NET developers easy by working on Akka.NET, Phobos, and more..