Menu Sidebar
Menu

The daunting economics of cheap services

Reader Rob asks:

One thing stuck out to me reading this, and I was wondering if you’d be willing to elaborate on it further:
“The trouble is, the economics of selling a service for less than $10/month are damn near prohibitive.”
Would you mind explaining how you came to this conclusion? Thanks!

 

I’ll be honest, I pulled this number out of a hat. I’m pretty sure I’ve seen others put the cap a lot higher than that.

It comes from a combination of factors. For one thing, costs don’t scale linearly, for the same reason that sales taxes hit the poor harder than the rich.

Just as a for instance, many payment processors charge something like $0.35 plus a percentage for every transaction they handle. The percentage is the same no matter what you charge. When you’re taking in $100/mo, the $0.35 part is meaningless next to the percentage part. But when you’re dealing with $5 or $10 transactions, it’s actually a significant added cost overhead.

An even bigger factor is support costs. Resolving a customer’s problem is going to cost roughly the same amount in terms of person-hours regardless of what you sell your service for. When you’re down in the $10/mo realm, a single problematic customer can offset several customers-worth of annual revenue in terms of time spent helping them.

There’s also the fact that the lower the cost of your service, the more customers you have to find. Which means you have to aim for something more crowd-pleasing. Which is harder, and there’s going to be more competition.

If you can find 500 people for whom your niche product is worth $500/year, you have yourself a respectable income stream. To get the same income from $100/year, you have to manage to convince 2,500 people to part with money. Which realistically means you have to a) find a niche with at least 250,000 people in it; of which b) you will reach 25,000 with your marketing (which is not free), and if you are lucky c) convince 10% of those people that your thing is worth it.

You may think “I will develop a stable of small, cheap services”. Which is a real strategy that some people pursue, and some even succeed at. The problem here is the same problem we run into with multi-threaded code: even with multiple cores, CPU attention doesn’t scale linearly. Neither does human attention. Context-switching tends to eat a greater percentage of overhead with every context you add.

It’s not an insurmountable problem. But you had better be ready, willing, and able to delegate everything, or it will eat you alive.

You might also think “I just want a side income stream”, but this point of view comes with its own risks.

Software Entrepreneurs: Stop looking for itches to scratch

On probably half a dozen different occasions some aspiring entrepreneur has asked me:

Would you be interested in a hosted solution for selling screencasts?

In most cases, the promised solution never goes beyond talk. In a few cases I’ve been sent invitations to beta test. In all cases, a successful business has failed to materialize, and 6 to 12 months later the domain is up for grabs.

These results are completely predictable, for a few reasons.

Read More

Three Object-Oriented Programming Books Worth Reading

A friend asked me to name my top three object-oriented programming books.

I found this a little bit difficult to answer. It wasn’t a matter of narrowing down a large field. Rather, at first I wasn’t sure if I could come up with all of three books worth recommending.

This is mostly my fault. I have shelves full of books on OOP, but I’ve only gotten around to reading a subset of them. There are probably a few gems in that collection and I just don’t know it yet.

But another factor is that there just aren’t a lot of good OOP books out there. Many of them have good ideas, but are written in a style that’s drier than Death Valley. Others come from the formalist school of object-oriented design, which co-opted the terminology of object orientation while denying the spirit.

Here’s the list I ended up sending him:

(Those are Amazon affiliate links; using them will send me beer money.)

These are all fantastic books that I can recommend unreservedly. Unfortunately, I don’t think any of them really qualifies as a on true 101-level primer on OOP thinking. If you can recommend an intro-level textbook on OOP which is neither a) a snoozer; or b) hung up on tangential stuff like types and inheritance, please pipe up in the comments.

EDIT: there is another book that I considered adding to this list: Object Design, by Rebecca Wirfs-Brock. I actually quote this book more often than any of the others on my list. I only left it off because (please forgive me Rebecca, you know I’m a huge fan!) it’s a tad on the dry side. I know a few people who had difficulty getting through it. If you’re like me, and you can get through a book that has a lot of lists of terms that are then broken down into further lists of terms, by all means read this book! You will be the better OO designer for it.

 

Older Posts

Virtuous Code

"The three virtues of a programmer: laziness, impatience, and hubris" — Larry Wall

Books and Screencasts

RubyTapas Screencasts

RubyTapas Screencasts

Small plates of gourmet Ruby code.

Confident Ruby

Confident Ruby cover

32 Patterns for joyful coding.

The Making of Cowsays.com

Confident Ruby cover

Watch me build an app in Sinatra and Rails

Objects on Rails

Objects on Rails

A developer notebook on applying classic Object-Oriented principles to Ruby on Rails projects.

Exceptional Ruby

Exceptional Ruby

The definitive guide to exceptions and failure handling in Ruby.

Archives

Categories