Xobni Man Walking Some thoughts from an entrepreneur

(Edited: fixed a few accounting mistakes towards the bottom.)

Suppose you wanted to make $1 million per month by selling software. You can either go for a few lucrative customers or lots of low paying ones. A half minute in Excel and you have a table.

Ten minutes in MS Paint and you’ve got a nice graph.

The sweet spot for high margin software offerings seems to be in the sub-$10 per month range. Rhapsody charges $13 per month. Yahoo Mail is $1.60 per month. Mozy is $5 per month. [1]

Enterprise customers pay in the same range for commoditized products. MS Exchange costs about $10 per user per month. FogBugz costs $20 per user per month. I’m sure enterprise antivirus is a brutal market for providers, but I don’t have numbers because they don’t have public pricing.

Enterprise customers are willing to shell out the cash in non-commoditized product categories, though. Salesforce.com charges about $100 per seat per month, but they’re going to have to drop their prices soon because of pressure from Microsoft and others. Bit9 is a new kind of enterprise security, so they’re set for a couple of years.

Anyway, so this is the range we’re interested in:

How do we get 100k paying users? Just for fun let’s assume that you have a freemium model. Most users aren’t going to pay, but some will because they get the bike horn that makes the moooo sound.

The rule of thumb is that about 1% of free users will convert to paying customers. The number varies greatly by vertical, product, etc., but let’s just go with 1%. Some quick math and you have another table.

So if you charge $10 per user per month, and 1% go premium, you need 10 million users to hit $1M in revenue per month. For reference, Outlook has 500M users, Skype has 200M users, and Thunderbird has 8M users.

Skype had about 50M users when they were bought. At that time there were about 4M people simultaneously online, so only a fraction of those 50M were active. Why did they get bought for billions? My guess is that a large portion of active users were paying customers. They were obviously still in growth stage. They also enjoy high margins and had recurring revenue for each user.

So what would $1 million of revenue per month do for you, anyway? $12 million in annual revenue, to be sure. Beyond that you’re back in the land of heuristics. Google has a P/E (price to earnings) ratio of 50. If you got the same ratio with margins of 50% then your company would be worth a nice $300M.

Margins vary hugely by business. Grocery stores get about 2% margins in a good year. Software, luckily, traditionally has high margins because the cost of supporting an additional user is so low. 50% sounds extreme, but consider Skype. They don’t have infrastructure costs, and they probably have no more than 50 or 100 people. That’s the kind of company Xobni can be. This 50% margin on $12M annual revenues can support a burn rate can support a head count around 30 or 40 people. That’s not a bad place to be when you hit the $1M per month milestone.

Other public tech companies have similar but not higher ratios. Redhat is at 65, Yahoo is 50, Sun is 40, Oracle is 30. Microsoft is 20, but damn do they have lots of revenue! Salesforce.com is 1053, but until recently was infinite. They’re still selling the dream.
These numbers can end up all over the board. Zimbra sold for $350M on revenues of about $15M, and probably way lower profits. The list goes on. Growth and strategic value to acquirers seems to have the biggest impact. [2]

With some more elementary school math, we can use these numbers to derive a value per user. An average user on the $10 per month row gets us ten cents per month, or $1.20 per year. That’s sixty cents of profit. With a 50 P/E ratio, that’s $30 per user, not far from Fred’s numbers.

P.S. Xobni is hiring. We are currently looking for great software hackers and a senior QA lead.

Notes

[1] The sad part about these prices is that both Rhapsody and Mozy are low margin businesses. Rhapsody is net losing money per user. Yahoo Mail is a high margin business, but it doesn’t matter because the price is so low.

[2] If you want more examples, look here for a list of MS acquisitions, and have fun googling.

(This message was pre-recorded.)

I usually edit two pieces of code when I’m squashing a bug. First I fix the specific bug, and then I go on a hunt for ways to prevent similar bugs in the future.

Can I make the code fail faster?

Bugs that happen earlier in the execution path are easier to investigate.

If an invariant was destroyed, the sooner you detect it the better. It’s great if you can check for the invariant right after you modify the data. If you have complex invariants then you might consider adding a CheckInvariants() function that gets called periodically.

If the bug doesn’t throw an exception, can you test for it and throw an exception when the condition occurs? Exceptions codify error conditions. If you collect exception reports then you’ll know how popular a bug is, you can see patterns of occurrence, you’ll know for certain when it’s fixed, and so on.

Can I make the bug more apparent?

The worst bugs only appear if the user is running Japanese Windows and singing in the shower while holding the control key. As a programmer I don’t do that often so the bug won’t be caught until release. Bugs get exponentially more expensive the longer it takes to find them. You will fix bugs earlier if you can make them more apparent, and everybody wins.

This principle is true even at the small scale. There’s a product category just for apps that tell you when you broke the build one minute after it happened. [1] You get to fix it quickly, instead of getting the email from your annoyed coworker one hour later. There are real dollars there.

Can I make this bug easier to fix in the future?
You might be able to make the bug cheaper to fix if it reappears two months later. Add a comment block detailing how the bug happened and how you fixed it. Reference the bug’s ticket number. Modify the code to include more relevant info in the error report.

One of the things I hate about C# (and Java too?) is that you can’t get the locals of a stack frame. This feature would save us lots of time and money when deciphering error reports from the field.

Can I make the bug impossible?
Wow, wouldn’t it be great if you could do this for every bug??

We don’t use static code analysis at Xobni yet, but that’s something I’d love to change. It can catch so many simple problems. You hard coded a string instead of putting it in the internationalization string table. You write ‘if(x == null) x.Foo()’ instead of !=.

Can I make the bug more obvious to humans?

Great software design makes bugs obvious. Is there some refactoring I can do to make the bug scream at anyone who reads or writes it?

Bonus!
I also like to comment out all exceptions before shipping a release build. That way users never see any errors! [2]

Notes

[1] This idea is called continuous builds. We recently implemented continuous builds and we all have fewer headaches.

[2] (From the joke department.)

[8:01:54 PM] Gabor Cselle says: public enum Options {
Chipotle,
Subway,
Quiznos,
Other
}
[8:02:46 PM] Gabor Cselle says: // yes, we’re pretty predictable, it’s safe to use an enum here

[8:03:36 PM] Adam Smith says:
List open = new List();
foreach(Options option in Enum.GetValues(typeof(Options))) {
if(IsOpenOnLaborDay(option)) {
open.Add(option);
}
}

Adam.OutputStream.WriteLine(Array.Join(open.ToArray(), “, “);

[8:05:42 PM] Gabor Cselle says: internal readonly Person k_nerdContestWinner = adam;

I deleted a big chunk of code recently. It was written months ago and just wasn’t in use, so it needed to go. There’s always an emotional attachment to code, though, so deleting it is like burning up your old love letters. You know you should probably do it, but you’re conflicted and it’s painful.

I bet the people who set off controlled forest fires have a similar feeling. They have to burn down trees and fauna that they helped create. But you’ve got to toss out the old to make room for the new.

Luckily, though, there’s source control! You can delete whatever you want and it will still be in your revision history. You’ll never go back and restore deleted code, but knowing that you could helps you do what’s necessary.

As I write this, I remember that there’s a whole namespace in XobniCommon that needs to die. I’ll take care of that tomorrow.

I played squash today with Nomi from Peanut Labs. We’ve been playing together since we both started relearning the sport. We played six games and he won four of them.

It’s really good for me to play someone who’s better than me because they bring me up. I think that’s a good strategy for life – challenge yourself.

You know you’re challenging yourself when you lose or make mistakes. It comes with the territory. So if you’re not failing then you can’t be challenging yourself, and that is surely a bad thing.

Let’s apply this to girls instead of startups. If I’m ever more than about 25% successful with girls then I don’t think I’m challenging myself enough. If I’m significantly less than 25% successful, I’m challenging myself too much.