Selling software isn't like selling cars or real estate. Don't sell yourself short.
This Q&A is part of a weekly series of posts highlighting common questions encountered by technophiles and answered by users at Stack Exchange, a free, community-powered network of 100+ Q&A sites.
deviDave asked:
I was asked to sell the source code (along with existing users) of small utility app I created years ago. I've investigated how to put a price on the source code but so far haven't come up with a good solution.
I've searched the net, but I haven't found anything useful. Then I came across a few others who also sold their source code with users, but their prices seem unrealistically high. For example, one person calculated price per user at about $200. He had 80 users and ended up selling the source with users for $30,000. How did he come up with this price?
Can I find a good price with this formula:
(number of users x app price) + (app price x num of new users in one year)?
If this is a good formula, how do you price source that doesn't yet have users?
See the original question here.
Treat it like a business
Mathew Foscarini answers (57 votes):
Selling the source code for an app is very much like selling a business.
The standard formula is
price = revenue * 3 + assets.
The multiplication of
3 is a factor of supply and demand. The more buyers a business has the higher the multiplier. When we hear about a business being purchased by ABC Corp in the news, it's often for a large figure. Those businesses can have a multiplier of 5 or higher.
For businesses that don't have a
revenue history, then they depend upon an evaluation. The evaluation is an estimate of projected revenue and the multiplier is applied to that.
So we can calculate the multiplier for your example;
1.875 = 1600 / 30000 = (200 * 80) / 30000
Assuming he sold all his licenses in 1 year, he (your example) would have a multiplier of
1.875 with no additional assets. That's not a very good deal for the programmer. Especially when you factor in future upgrades from those users adding to revenue.
Why is it not a good deal?
The buyer can recover his costs in less than 2 years. Most people take longer to pay off a car loan.
When we speak to the buyer in terms of setting a price, we discuss how long the buyer would like to recover his investment and start profiting from his purchase.
You are saying "I'm giving up this source code, and its future revenue to you." The price is set based upon an estimate of what the future would be.
If you have not received any revenue from your source code, then you will have to argue with the buyer what the evaluation of its future revenue will be.
Get back inside your head
BrianDHall answers (33 votes):
The hardest part of doing this sort of thing for the first time is really psychological—there is a very strong tendency to think of what it cost you in man hours, which is usually wildly inaccurate when done retrospectively and ignores the "I wasn't sitting at a desk but I was thinking about that algorithm all day..." factor, as well as other overhead details, etc.
So I'd like to invite you to change your frame of perspective using an analogy: you no longer have an app, you have a steel widget. You put things into it, and things come out the other side, and what it does to the things that go in have caused various people to become accustomed to having your widget around. To date, you've just been giving your widget away for free because someone gave you the steel for free so it doesn't cost you anything.
The Background Concepts
Now someone wants to buy the whole concept and user base of your widget from you.
First of all, why do they want to buy it? If it's a business, the answer is "to make money." Either they are improving an existing product they have and wish to increase loyalty and offer a benefit they think could sell more copies, or they want to avoid solving a problem they have and thus reduce costs or focus their own effort on other things. They might also want your users as potential "hot leads" who they know could be interested in their product and could be unusually likely to buy stuff from them.
The relevant equation:
Price Paid = (Buyer's Perceived Value - Seller's Cost) * Negotiation
So if it costs you nothing (you already did the work without expectation of pay), and it's worth $100k to them, do they pay you $1? Or $99k? $50k? It's all about negotiation—trying to determine where the final price is between the maximum they'll pay and the minimum you'll accept.
Sometimes negotiation is so weird that people pay too much, and sometimes people sell for less than cost. These are edge cases, and so we ignore them—but yes, they do exist. I want to hire Instagram's negotiators for everything I do ;)
So first, what's it worth to them? This is by far the hardest thing to know, and one tactic is to flat out ask them. I know, crazy right?
Super Secret Negotiation Tactic
"I'm a reasonable man—what's this worth to you?" or "What's your budget for this sort of acquisition?" You'd be amazed at how often people just flat out tell you. They might not want to haggle, and if they just want to do their job and buy something from you and go on with their day, they could just tell you, "We've got about $50k in the budget for acquisitions like yours, and yours is relatively small compared to some of the other things we are buying, so we figured 5-10k would be reasonable given the straight-purchase we are requesting." Or "We figured it would cost us about $4000 in expenses to make this ourselves, so that's the most we'd pay under any circumstances," or simply "We're looking to seal this deal at around $3000."
And then you get to decide if that's ok with you and if you want to push it or take it. How hard was that? In negotiation it's almost always very important that you must not be the first one to name a price—so if they volunteer a price then you have a baseline you can accept outright or argue up from. But they might not name a price, and we have to see if that price is reasonable anyway.
There are a few accounting systems to determine the value of something, and this is what a rational business will use to determine a budget for buying your little entity:
- Cost: The value is what it cost, perhaps with yearly depreciation. This is the most common form of accounting in the world, and it literally says "the value is whatever it cost to buy it, decreasing over time." Seriously—it costs what it costs. Not very helpful to us here, but its true.This is what people try to do by determining man hours, but I'll give you the bottom-line: this is meaningless in software. You can work 40 years on a million lines of code with a going rate of $50 an hour and the result is worth $0. You aren't freelancing or accepting a contract to build something at an hourly rate, nor did you make it "on spec" with the hope of selling it to recoup your expenses. This is psychologically pleasing, but utterly meaningless in the context of buying and selling.
- Replacement Cost: The value of something is what it would cost to replace it. This can be easy with commodities, like asking "what is the value of a new Ford Focus?" But this is not so easy in software, because it can be like math—a single one line formula could take a century to discover if you don't already know it. Or what took you 10 hours could take someone else 100—or maybe it would take them only an hour.So this would look at trying to estimate what it would cost to have a replacement for your widget built that simultaneously doesn't violate any of your rights as an inventor. Looking at the lines of code/complexity/difficulty of your app would produce a range of anywhere from "maybe a month for a prototype that is low on bugs if one person who knows what they are doing works on it" to... who knows. It must not be trivial or they wouldn't offer you money at all.If they have their own development team maybe their estimate of doing it themselves is very reasonable. But they don't want to—they have more important things to do with their time. They'd have to wait for months to get started, or they would have to hire someone—and who knows if they can deliver or if it'll just be a waste of time and money? There's so much risk!You've got the goods Right NOW, and this has a special value. Take advantage of this.
- Comps (short for "comparisons"): This is what other things are going for. For example, if this business is used to buying apps/users/source code, they can say, "Well, this widget is easier to make than the SuperWidget we bought last month for $10k, but the output isn't as marketable as our DeluxeWidget we bought last year which we paid only $5k for." So perhaps they figure a comparative value is somewhere between $5k and $10k, and it doesn't matter if you have a million lines of code or 10, they don't have to know or care.This is how most non-commodities are sold (like real estate). It's a great system, and it's what you were trying to research, but in this market (software) there is very little public data, so you are at a disadvantage of being in the dark on this. Understand, though, they probably have more data on this than you do, and it is probably part of how they figure what they want to pay you.
- Income Multiple (Projected Sales) System: As Mathew Foscarini pointed out, this is a system used to value business and commercial real estate properties.The idea is that you have an asset that generates an income. For instance, an apartment building takes in $50k per year in rent. Then there is a Multiple applied, which is based on the comp system (mentioned above), say 10. So the market value of this apartment building is how much rent can be collected, based on current occupancy and rent rates, over 10 years = $500,000. Of course if you raise rents and improve occupancy next year to get an extra $10,000 a year in rent, suddenly your property is worth an extra $100,000—and thus why so many rich people (and bankrupt people, too, of course) are involved in real estate.This system can be applied to software, but if your app isn't individually commercially viable it's hard to do this. With your example of 80 users paying $200 each, that means that if a company can convince those same people to buy a new version (which is way easier than selling to strangers), or convince a small portion of their larger client base to buy 80 copies, that's a quick $16k for maybe sending out an e-mail blast and sending a memo to your sales staff.Good established companies have estimated lifetime values of users, and if this number is high (like, say, Adobe's buyers of Creative Suite), then paying $30,000 to pick up even 1 new user or retain an existing customer was a great idea.
What You Should Do
The first step is "talk to them." Learn about their needs, why they are interested, what need does this fill for them, just learn as much about them and what they want as possible. This is Being A Good Salesman (not a sleazebag salesman)—get to know your customer.
Maybe they are actually buying to resell. I've had people offer to buy code of mine because they had a contract where they were supposed to make something that did what my code already was doing. If their total contract was $500, obviously the most they were going to pay me was "less than that." I asked and they pretty much flat out told me just like that. Sometimes I wasn't interested (it wasn't worth the hassle to me for that price, or I was too busy), sometimes I just gave them the code for free, and sometimes I took them up on their offer to make a little extra money on code I already wrote and could still keep using.
Maybe they want to reskin/repurpose the app and sell it as their own product. Maybe they want to add it to a menu of their existing software. Maybe they don't care about the app much but want the users and the app to be a free bonus given to buyers of their next version. Maybe it will be compiled into their own source code and the existing app will be "discontinued" but the feature will be available in their app now... etc, etc, etc. I could make stuff up all day long, but the only way to have even a vague idea is Just Ask. Even if they lie, who cares, you learned something!
Sometimes these are job interviews of a sort and they'll want to buy your services in the future, maybe they just want a widget to save them the trouble.
Final Caution
The devil is in the details, and they matter. Do you retain ANY rights to the code? Do they even want you to stop using/delete all copies of the code and the app of your own? Do they just want a license to use your stuff and to "transfer" the name and users to them and they could care less what you do after that? Do they want ongoing support, consultation, and if so what is appropriate to contact you about and when?
If they are to make future demands of your time and effort, that is a good time to offer something like "x hours of support in the transition/interpretation, then I'm available at $Y per hour after that." Be interested, be professional, be supportive—don't give yourself, your time, and your work away because you forgot to clarify and put things in writing.
Find more answers or leave your own at the original post. See more Q&A like this at Programmers, a site for conceptual programming questions at Stack Exchange. And of course, feel free to login and ask your own question.
Courtesy: arstechnica
0 comments:
Post a Comment