Skip to content

How to Legally Steal From Your Customers

In early October, I had the pleasure of meeting Harry and Ted from Moraware Software at the Business of Software Conference in Boston. They’re apparently big fans of the Startups for the Rest of Us podcast that Rob Walling and I run. We had more than a couple of discussions at various points in the conference, but this one sticks out the most.

iStock_000015000686XSmallI’ll credit Ted for this particular blog post, since he brought up the topic. Over the past year or so, Moraware Software has transformed its pricing model from that of selling software outright to Software as a Service(SaaS). Their rationale? Mostly it had to do with interesting quirks associated with how accounting is done.

You see Moraware, like the vast majority of software companies on the planet, was stealing from its customers. And before you go off the deep end, let me state plainly that this is a common and widely accepted practice which is completely legal. The details are in the accounting.

Let me explain how it works so that you can steal from your customers too. Trust me. They’ll love you for it.

The Dirty Secret to Downloadable Software

Selling downloadable software certainly has its pros and cons. More specifically, for downloadable applications the price points tend to be higher in the short term and the cash injection is more than welcome for most companies just starting out.

But here’s the dirty little secret that nobody ever talks about. The vast majority of software applications offer support for some period of time after the purchase. Many offer a money back guarantee as well, because lets face it. There’s very little to lose by doing so if you’re offering a genuinely good product.

But guess what? Until that support period and money back guarantee have expired, that money isn’t yours. It’s what’s called “deferred income”. Straight from Wikipedia, the source of all truth in the universe:

Deferred income (also known as deferred revenue, unearned revenue, or unearned income) is, in accrual accounting, money received for goods or services which have not yet been delivered. According to the revenue recognition principle, it is recorded as a liability until delivery is made, at which time it is converted into revenue.

Thanks Mike. What the hell does that mean?

The basic concept is simple. Assume your support period is 1 year. Every time you make a sale, only 1/12 of that income should be applied to your revenues on any given month throughout that year. What you should technically do is set that money aside until the month in question, at which point you can access it and spend it. Otherwise, you’re spending money you’ve received from the customer before you’ve delivered what you promised.

An Example

Suppose that you’re selling two different products:

  1. “Spin, Spin, Spin”(SSS) is a downloadable software application built for people who are into the indoor cycling sport known as “spinning”. It tracks your physical statistics and compares them to stats from your training buddies. It costs $120 up front and comes with 12 months of support.
  2. “Shake Your Moneymaker”(SYM) is an iPhone app built to measure how well the phone (and most likely other parts of you) move in your pocket while you’re dancing. It’s a social phenomenon sweeping across the island nation of Elbonia and for a mere $10/month, you can compare your “moneymaking skillz” against those of your friends and enemies.

Scenario 1:

Assume that you sell SSS to Customer A in January. Chances are pretty good that you’ll get that $120 and spend most of it before the month is out. You’ll plow that hard earned cash back into the company to do additional software development, provide additional enhancements or simply pay for additional business expenses.

Guess what? If you spend more than $10 of that money in January, you’ve just stolen money from your customer. They’re probably not going to care or even notice unless they ask for their money back, but it still happened. And the reason is because you didn’t set that money aside and account for it properly.

Scenario 2:

Assume that you sell SYM to Customer B in January. This customer is paying you $10/month for each month of service. You provide the service for a month, and then the customer pays you for another month of service. No harm, no foul.

In Scenario 2, we’re spending money as we provide a service. In Scenario 1, we’re spending money prior to delivering a service, which in a way is theft.

What the hell are you talking about? That’s not stealing!

You’re right, it’s not. But you still spent money that isn’t yours. At least not yet it isn’t. So you borrowed without permission, which in most cases is stealing. But this is a socially and legally accepted way of doing business, so from now on, I’ll call it borrowing from you customers. At the end of the day, what’s wrong with doing this?

The fundamental problem with spending money you’ve received before you provide the service isn’t so much that you’re stealing. The underlying problem is that you’re operating your company on credit that has been extended to you unknowingly by your customer. Your customers have credited you with that revenue, but you’re still on the hook to deliver services for the next 12 months.

This means that when you look at the monthly bank statement, it says you have loads of money. But when you look at your accounting statements, they’re going to show that even double digit growth doesn’t make you significantly better off than you were before the sale because you are carrying a liability that is equal to the sale price, minus 1/12 for each month that passes.

Is this really a problem?

Yes. The problem with downloadable software is that it’s much more difficult to identify sales trends. When you are selling downloadable software, you basically start from $0 every month.  So every month becomes a new sales cycle. An off-month can easily derail many of your sales projections and make it difficult to determine definitively whether you simply had an off-month, or if your business is in the middle of a mild (or severe) downturn. It can take months for you to find out the answer and those months can make or break your company.

With SaaS, you have a base of customers and each month it’s extremely easy to tell if you are doing better than you were in the past by looking at your customer base. If you have more customers at the end of the month than at the beginning of the month, then your business is growing. If you lost more customers than you acquired, then your business is shrinking.

When you sell downloadable software, the picture isn’t nearly as clear.

When is Selling Downloadable Software a Good Idea?

I’m glad you asked. One-time fees for software are a great idea when you’re just getting started with your product. This assumes that the cost of your product is in a reasonable range that most of your customers are going to be able to buy without too much trouble. Generally that means less than $2,500 or so per purchase. Beyond that, the sales cycle tends to be a bit longer and therefore becomes more difficult to close the sale.

But in the beginning of your fledgling company, the cash injections you get from those initial sales will do something for your company that a SaaS offering won’t do.

These early sales will provide you with the capital needed to help develop your product.

And that right there is generally reason enough to license your software per sale rather than as a subscription based service. Just keep in mind that when you do this, you’re building your business on a line of credit offered by your customers.

11 Comments

  1. […] This post was mentioned on Twitter by Chico Startup RSS and Mike Taber, Matthew A. Snell. Matthew A. Snell said: How to Legally Steal From Your Customers http://is.gd/iQqIs […]



  2. Ted on December 16, 2010 at 10:02 am

    I think an important point is to match up your price with the value delivered.

    If customers get most of the value up front, you need to charge for it up front. But if they get consistent value every month, you’ll be much better off selling a subscription.

    In the second case, the subscription is usually easier to sell, because customers don’t want to pre-pay for uncertain value 3 years down the road, unless you’re severely under-pricing your product.



  3. Mike Taber on December 16, 2010 at 10:24 am

    Very good point Ted. Although hopefully your software will deliver value long after they first start using it.



  4. Ryan on December 17, 2010 at 9:35 am

    So how would you make the transition from a one-time fee based sale to a subscription based sale.

    Is it as easy as flipping a switch and hoping no one notices? Do you still offer support for people who got your product via one-time fee?



  5. Ted on December 17, 2010 at 3:00 pm

    @Ryan – Yes, we simply flipped the switch about 18 months ago. The change only affects new sales, so nobody complained.

    For customers who bought a perpetual license, they still get the exact same support they had before. (They still pay the same annual maintenance fee as before.)

    It’s just like any price increase. If you already bought, you’re unaffected. If you’ve been waiting to buy, at worst you think to yourself “I should have bought sooner.” But that’s a good reaction.

    If you have customers in your pipeline, you can give them a few weeks warning, which may give you a great temporary sales boost as well.



  6. @clogish on December 20, 2010 at 3:47 am

    I suspect there would be a legion of Financial Accountants and Auditors who would become apoplectic upon reading this.



  7. Mike Taber on December 20, 2010 at 8:35 pm

    I don’t really think so to be honest. The fact is that developers are not accountants and neither I nor most accountants would expect a developer to know a lot about the details of accounting. Thus, this blog post because most developers don’t know a lot about accounting.



  8. @clogish on December 21, 2010 at 6:52 pm

    No, really, suggesting that spending revenues which have been received against future product/services is in anyway sensible or legal is misleading.

    Sure, it happens, but by your own admission it’s “borrowing without permission” and if you’re into that, you’re probably quite happily declaring it all as revenue in the month the payment was received. A game best not played nor advocated, in my opinion (and that of many regulatory bodies).

    Suggesting that a developer doesn’t know, or isn’t expected to know about accounting (and if they run a business, they are expected to know or get advice) doesn’t in any way make it acceptable practise.

    Of course, IF the accounting is done correctly, then there is a different perspective to take, but that doesn’t appear to be the point of the article.



  9. Mike Taber on December 21, 2010 at 9:51 pm

    “No, really, suggesting that spending revenues which have been received against future product/services is in anyway sensible or legal is misleading.”

    That’s not what I said at all and I’m not entirely sure how you got the impression that I would advocate against sound accounting principles. When you spend money up front that you should have accounted for as deferred revenue, you’re running your business on credit lent to you by your customers. ie: regardless of how much money you “think” you have in the bank, chances are good that it’s not all your money until 12 months from now.

    “Suggesting that a developer doesn’t know, or isn’t expected to know about accounting (and if they run a business, they are expected to know or get advice) doesn’t in any way make it acceptable practise.”

    I never said any of those things either. What I said was that I wouldn’t expect a developer to know a lot about accounting. To give another example, I wouldn’t expect an accountant to know a lot about writing code. I never said they shouldn’t know it, merely that I wouldn’t expect them to know it because developers tend to concentrate on writing software.

    When it comes to things like accounting, business operations, logistics, hiring, sales, marketing and a host of other things, most developers either assume that it’s so easy they can do it with their eyes closed, or they close their eyes and hope for the best. That’s an observation. I’m not advocating for doing it.

    I’ve seen a lot of people go down the road of spending money before it’s truly theirs and from an accounting perspective, it’s legal because they do all their business like that. But it’s not a good idea from a business perspective because it’s difficult to truly judge how your business is doing. What’s not legal is to pick and choose what revenue you account for on a cash basis, and what revenue you account for on an accrual basis. You can probably switch models at the end of a fiscal year but it’s probably going to be ugly for whomever’s doing your taxes.

    My hope with this article is to spark some conversations around the fact that developers who are starting a business need to understand some basic accounting. Not a lot mind you, but the basics. The details, their accountant can handle, which will let them concentrate on the rest of the things they don’t want to have to look at. 🙂



  10. @clogish on December 23, 2010 at 10:53 am

    “it’s legal because they do all their business like that” – it’s lines like this that made me boggle, although I grant you did follow up with it not being sensible.

    I understand you are trying to stimulate conversation, and perhaps my direction of conversation wasn’t what you were hoping for. It’s probably sensible that we agree to disagree 🙂



  11. Nikki Hebert on December 29, 2010 at 1:59 am

    No, really, suggesting that spending revenues which have been received against future product/services is in anyway sensible or legal is misleading. Sure, it happens, but by your own admission it’s “borrowing without permission” and if you’re into that, you’re probably quite happily declaring it all as revenue in the month the payment was received. A game best not played nor advocated, in my opinion (and that of many regulatory bodies). Suggesting that a developer doesn’t know, or isn’t expected to know about accounting (and if they run a business, they are expected to know or get advice) doesn’t in any way make it acceptable practise. Of course, IF the accounting is done correctly, then there is a different perspective to take, but that doesn’t appear to be the point of the article.



Leave a Reply