Pricing a Simple, Useful Desktop App I've grown tired of giving software away. So, I want to experiment with recouping some of the costs. I'm wrestling with pricing. I don't want to go too low as I'm concerned people will think it's cheap, and not too high as I want it to be easily affordable by average folks. I see value in micro-payments, but google check-out charges 2.9% + .30 cents a pop. So, I need the range (I think) to be $5.00 to $25.00. I feel both extremes are bad. Any suggestions? |
Seriously. Whatever number you're thinking of, it is too low. Think of a number that makes you wince. That number is too low, too.
Many people here will suggest you charge like $5 or $10. These people are unwilling to buy your application at any price. They are not your customers. Their opinion on your price is irrelevant. (I mean this in the nicest possible way, guys.)
Charge for value. It isn't a "little" app or a "simple" app. Your customers are not programmers and do not know how many LOC it was (or, on the other extreme, how much loving care you put into it). They only see the value delivered to them. Price appropriate to the value.
People pay more money than you will ask, far more, for things which matter far less to them. Always remember that!
Charge more.
If someone is going to open their wallet and bother to enter a credit card number on your site, $10 is the same as $25. If your product saves someone a few hours of effort, $25 is a trivial amount of money to buy that time -- you will have a sale.
Don't compete on price -- compete on provided value. Make your app the best way to resolve 'Task X' and people will buy it.
Ignore those people who say you're too expensive. If they're wincing about $25 you really do not want them as a customer. Back when I priced software to be competitive 'on price', I attracted people who were looking for the cheapest solution and those people are, by far, the biggest pain in the tail for support that you will ever run into.
I understand that you meant that it's easy to underprice the app, but as a generic pricing guideline this advice is wrong.
Not considering running operational costs, the price should maximize (price x sales) figure, i.e. the revenue. It's true that in some cases doubling the price cuts the number of customers in less than a half, in which case the the "charge more" advice stands. But in other cases charging half of the current price may easily quadruple your paying userbase.
Finding the right price can be done only through trying different prices. At some point Amazon was giving random discounts to their users and trying to pinpoint the ideal price for the item. It didn't last long, of course, as people started gaming them, but it just goes on to show that the price validation is a big deal.
Also keep in mind if you start with $200, see zero sales and then start gradually reducing it to $20, then you basically shoot your own credibility as a merchant as the $200 -> $20 drop makes you look greedy, detached from the reality and ultimately incompetent.
In the end it all very much depends on the application and the target customer base.
I think you will find in the typically B2C sales cycle -- which is a term that makes me laugh, since it typically fits inside a browser session -- customers do not have access to the contents of your lunchbox from last Tuesday or your pricing strategy from yesterday. The only thing they see is your price, today. This is one reason that nearly everyone who starts at $200 and goes to $20 fails -- not because they "lose credibility" (no one saw the $200 price -- really, no one, the no sales problem in software is almost always caused by the marketing strategy "Put up a website and pray someone discovers it") but because charging $20 for applications communicates that the value provided by them is negligible.
(Relatedly: your competitors' pricing does not matter because your customers will probably never see it.)
Are you suggesting that the other direction is preferable? I would think that it would be worse to keep jacking up the price.
What others haven't mentioned yet is that this also gives you an excellent user base for any future products you decide to create and release. Would you want to market your next product to an existing customer base of a bunch of cheapos, or people who have prequalified themselves as individuals whose time is worth serious money and are willing to pay up for good quality fixes to their problems?
I know of one who made a similar app for airgun users that is free but has nag screens but most everyone I know on the airgun forums have shot over (excuse the pun) the small fee to get rid of them out of gratitude for the app, which we all have found quite useful.
Try before you buy is the time honoured way of proving utility and value but that adds the cost of adding security to the app. Perhaps an unconditional money back guarantee?
Expecting people to pay anything over $5 for a command line tool is unrealistic. And if it is priced at $5, then it won't sell because $5 is just not worth a hassle of paying for the users. Unless, of course, there is a streamlined purchasing mechanism. One click checkout that pre-fills the credit card info and such, but again that's not an option.
I would strongly suggest creating a GUI version of the tool and then it may have a chance of selling at $10 to $20 range .. though again .. know thy customers - people who make the ammunition at home typically do so because it cuts their costs. This means that you will need to somehow convince these cheap bastards that your app is worth paying for, and it's not an easy thing to do.
I'd also suggest setting up a free web version but under a completely different name and domain. Slap on some relevant ads (Adsense, ebay, etc).
You're note going to destroy your market either way. You're not making anything right now, so experiment!
In my startup one of the mistakes we made early was pricing things too low.
Shooting enthusiasts are willing to pay money for software. Brian Plexico once sold several thousand dollars worth of a program written in a week, which just recorded scores for skeet shooting. One of the keys was ease of use -- again, NOT a command line.
http://www.microisv.com/archives/2006/03/06/conception-to-sa...
Talk with the old lady and put together a grand to take out an ad in Soldier of Fortune, then slap a big fat "Please see our ad in Soldier of Fortune" on your website.
SoF is such a highly coveted niche publication, the mention of its name is more profitable than the revenue generated from ads on it. "As Seen In Soldier of Fortune" has a nice ring to it, rhymes with "cha ching".
Again, Get it DONE!
Get Dev-Cpp; click Tools -> Check for Updates -> [scroll around to find a recent FLTK devpak -> Select -> Download.
Restart FLTK and New -> Project -> GUI -> FLTK.
Get it done!
Downside: Less of a percentage as your take. Upside: You're not hosting the store.
Also, I agree with others that trying to sell a CLI version will probably go nowhere. In fact, it may stifle adoption after you switch to the GUI version (since prospective users might think "Oh, that's that terminal program, right? Yuck!").
Amen on the GUI comments. Other than that, how would the program go as a value-add to manufacturers of specific supplies and/or equipment? If it helps increase sales and/or help people achieve increased accuracy and/or grouping then maybe some such suppliers might be prepared to have you brand the program for them to sell at gun shops.
Put them at drastically different price points. See which one(s) sell. Eliminate the price points/versions that don't, and roll their "benefits" upward (or downward, if you want to be nice.)
http://gui4cli.com/html/interface.htm
But FLTK will have better integration.
That's not what he asked, though.
I made my first $5 bill for helping my uncle take some stuff to the dump when I was about 8 years old. AND he bought me a coke, BONUS! And let me tell you, $5 was worth a whole lot more back then.
Sign up for one of the millions of free blog/file hosts. Don't bother with a real domain name. Google pages seems nice.
Thank goodness it's only you. I made a decent living writing database archiving tools as CLI utilities because the vendor supplied GUIs weren't scriptable.
How many gun owners do you know? I know a bunch. They're an odd group, insomuch as they are not as simple to peg as some might think.
Sure, some are Dukes of Hazzard beer swilln' hicks, but others are top-grade software developers, teachers, and engineers.
I'm skeptical about selling CLI apps in general, but I don't think it's made any better or worse when targeting gun owners.
(To the original poster: go grab JRuby and Monkeybars and bang out a cross-platform GUI version!)
Most likely the potential customers buying the app he built are people who don't know what a command line is.
I think that someone who is ready to drop significant change (money) on on guns and other shooting accessories (which aren't cheap), particularly as a shooting hobby, would be plenty willing and able to spend a bit extra for a smartphone. The phones have so many other uses; I imagine they, or rather their format and capabilities, are going to become standard fare within a couple of years (with the current economic "repression" being perhaps the biggest unknown factor in this evolution).
Also, many shooters are technologists, if of a different flavor. A lot of time and attention paid to materials, workmanship, and performance. The leap to an iPhone or similar may be less of a gap in terms of mindset than might be imagined. If it's a good and useful tool, they will appreciate it.
In short, many shooters may have the phones already, before too long. A few might be nudged into the addition expense by the availability and utility of applications such as this -- though I wouldn't count on such conversions of themselves for generating a significant market for the application.
I don't know whether it makes sense for the original poster to go this route. It obviously would involve significant additional time and effort towards learning the environment and porting the application. Also some significant expense for the development environment. On the other hand, I -- again, just off the top of my head, or perhaps out of my other end ;-) -- imagine real potential in the resulting marketplace to which the application would have exposure.
I could be quite wrong, but I'm throwing the idea out there for consideration/conversation.
This isn't all in place, yet, in a convenient fashion. But I can imagine it falling into place.
You need your phone with you, anyway, if nothing else then for use in case of accident, injury, getting lost, vehicle failure, etc. If it can do all these other things for you, well, that's the cat's meow.
If my imagination bears any resemblance to what evolves, it would seem to me to be a pretty decent market to sell into.
The cost of picking up a new platform to learn. The cost of hours spent kluding an iphone development environment on whatever his current desktop is. The cost of writing said app. The cost of submitting it to Apple and waiting for how ever long it takes for approval. The cost of time spent polishing the site so it fits with the glossy, round-cornered aesthetic of the iPhone (possibly learning a graphics package or hiring a designer.) The cost of waiting for the pennies to trickle in from the huge user base of gun-owning, bullet property measuring, badass iphone users who don't know of crackz sites.
That and the small issue of having to get a Mac if not already owned...
Who was offended? Not me. I'm pointing out a false view of gun owners. If Peter had in fact said "people completely at random" or "but they're not geeks", that would haven fine.
But emphasizing gun ownership as if it were particularly relevant (e.g., they are more likely than people completely at random to have trouble with the CLI) is bogus.
Oh, and quit being touchy. :)