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?
13 comments
The single best advice I've ever heard for pricing: charge more.
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.
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.
Exactly what I hopped on here to say. To add to it:
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.
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.
My story exactly. I get more issues, how to-s etc. in support email and site forum from people using the "Free Version" of my software
> Charge more.
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 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.
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.
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.)
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.)
>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.
Are you suggesting that the other direction is preferable? I would think that it would be worse to keep jacking up the price.
Are you suggesting that the other direction is preferable? I would think that it would be worse to keep jacking up the price.
I would say that you sell the program at several different price ranges: call one Standard and one Enterprise, and another Home, and so on. They don't have to be any more different than the various versions of Windows are—that is, about 1% alteration, basically features flipped on or off in the shipped client using flags built into the reg. key.
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.)
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.)
Well, no, not really. Overpricing by much is really bad. Underpricing is not good either, but can be remedied by releasing new versions under new pricing. Overpricing by little is the best though, because it allows fine tuning the price with sale or coupon discounts. So again it comes down to knowing the target userbase and making a reasonable initial guess.
Best advice. It has to hurt people when they type in their credit card details. If it doesn't, it's too cheap. You'll make far more money turning a few cheap customers away while capturing the surplus of people who actually have a serious problem to fix.
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?
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?
A domain name is $10 a year, and hosting at GoDaddy was about $4 a month back when I used it for selling downloadable software. "Recouping the costs" is setting your ambitions way, waaaaaay too low. (Indeed, if you're a professional programmer, the biggest cost by far is the imputed value of your time.)
Have you tried putting it online with a paypal donate button? That's worked wonders for our site and we make more than enough to break even. You'll find that firearms enthusiasts are generally a generous and thankful bunch and if you phrase a request for donation the right way they'll be more than happy to contribute towards your expenses.
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.
http://www.chairgun.com/offset/chairgun2.htm
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.
http://www.chairgun.com/offset/chairgun2.htm
I would tend towards the higher price as long as your app is good value. You always have to compete the the "I could write that myself" viewpoint - but make it clear that the $25 will save the customer several hours work and meet their needs and you probably have a sale.
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?
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?
If the software's any good, cracked warez versions will end up floating about anyway.
What does it do? What other software does the same thing and why is yours better?
It calculates trajectory, drop, etc of a bullet depending upon caliber, grain, powder, etc. It's command line only. It's windows only. No GUI, but it's very simple to use and accurate. Very useful for folks who reload their own ammunition. Covers all calibers from smallest to largest.
As a general rule, I don't pay for command line utilities. Put a shiny GUI on it and I'd probably reconsider. Plus command line applications are not user friendly (especially Windows based ones) and take more effort to run than a nice clickable icon and GUI. My suggestion, either give it away for free or develop it to a point where you can add a GUI to it (shouldn't be hard with a couple hours of C#) and then charge for it. I wouldn't pay more than a couple dollars for something so basic though. $25 is way too much.
As a general rule, I don't pay for command line utilities.
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.
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.
That's the sort of stuff technical folks want to be able to use (and script) from the command line. This guy has written an app for people who are into guns.
"This guy has written an app for people who are into guns."
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!)
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!)
Quit being offended. If we take "gun owners" to mean "people completely at random" (i.e. no prejudice) then what he said is true. Random people don't like CLIs. Random people are completely different than people who want to write database archiving scripts. Script writers like CLIs better.
You're right, but to be fair, James read my implication quite well. I was having a tiny dig at gun nuts - not from any realistic experience but mostly because I'm European and I'm culturally supposed to look at gun-toters with disdain ;-)
"Quit being offended."
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. :)
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. :)
The difference is that you're the target demographic for those database archiving tools: people who know how to use a command line.
Most likely the potential customers buying the app he built are people who don't know what a command line is.
Most likely the potential customers buying the app he built are people who don't know what a command line is.
Command line programs are not simple to use to anyone who is not a programmer. Wrap a GUI around it.
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...
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...
It calculates trajectory, drop, etc of a bullet depending upon caliber, grain, powder
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!
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!
You might get more money from making the application into a web application and getting commission from click-through sales of actual hardware.
Or you could try both... limit the web version some, and sell the desktop one.
It sounds to me like this would be a good candidate for an iPhone and BlackBerry app. How many people shoot guns when they're sitting in front of the computer (other than us developers)? ;)
How many people who make their own ammunition also own an iPhone ? Perhaps a dozen, and that's optimistically :-)
It's a bullet trajectory calculator. Only way I can see this thing making money is if it was made into a pocket-calculator type of thing and mass produced in Guangdong China.
It sounds to me like it's intended for developing custom loads for guns, not calculating ballistics in the field. The target market would be handloaders who sometimes spend thousands of dollars on reloading equipment. An ad-supported web app or a paid GUI app would be very viable.
I can't say more than that I would certainly not buy one, nor even use a free one. But then again, I can say the same thing about a bingo card generator too. Also, it looks like he's not trying to make a living on it, but simply break even or make a bit of extra cash.
[deleted]
You can get a 50k GUI with FLTK in less than half an hour, and it compiles to a static binary. The API is at about the same "complexity" as Tk and the bloody thing is in C++.
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!
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!
Wow... thank you very much! I've never heard of this library. Looks ideal. I really do appreciate it. I've been struggling with WX.
There is even GUI4CLI, which is a wrapping scripting language which generate GUIs for CLI utilities. It's used by Avanti, which is a GUI for ffmpeg and avisynth. It's about the same complexity as a clean tiny, basicish, shellish pascal:
http://gui4cli.com/html/interface.htm
But FLTK will have better integration.
http://gui4cli.com/html/interface.htm
But FLTK will have better integration.
What about making it an iPhone/Android/similar application? I envision people using it not just when reloading, but at the range, when buying ammo at the store, etc. I may be completely off in my opinion, but it seems the kind of thing that aficionados would drop a few bucks on. Some for making actual decisions; others to use as an adjunct/reference in conversation. And those phones are becoming a vast marketplace. For those using it for real work, other than reloaders, it would also place it at their disposal where they most need it: In the field.
Downside: Less of a percentage as your take. Upside: You're not hosting the store.
Downside: Less of a percentage as your take. Upside: You're not hosting the store.
iPhone app; for some reason I don't think the intersection between gun owners and iphone owners is big enough to justify the cost of development.
I am seeing iPhones all over the place, here in the Chicagoland area. And I'm seeing a lot of them in the hands of people I would hardly call technologists.
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.
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.
Bad form, perhaps, to keep responding to myself. But, where I used the word "shooters", consider also hunters. A real need to know trajectory under varying circumstances. Also a strong interest in location and orientation, where a smartphone GPS and onscreen mapping would be quite useful. Mapping of various sorts, including not just satellite and topo, but even property ownership; if you are hunting on private land or need to avoid straying onto same, it is useful -- perhaps critical -- to know the boundaries.
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.
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.
I'd like to hear more on this cost of development. The biggest cost would be buying the developers license. His algorithms are already written, so it's just porting them to Objective C and slapping a Cocoa Touch interface to it (which shouldn't take more than a day, soup to nuts with no Cocoa experience). Plus you get the added benefit learning a useful SDK.
I'd like to hear more on this cost of development.
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.
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.
The biggest cost would be buying the developers license.
That and the small issue of having to get a Mac if not already owned...
That and the small issue of having to get a Mac if not already owned...
If going with the iPhone/Android app what would your pricing strategy be? Charge more seemed to be a popular answer for a desktop app. Does this still hold with the online market place that allows users to more easily comparison shop?
It can't be that hard to slap a GUI on it with something like Tk, and that would probably make it a lot more attractive to people.
It's C++. I do have a GUI written using WXwidgets, but it's only 75% done. I thought I'd try to sell the CLI version first and if it is popular and pays for itself somewhat, then finish the GUI as I could then justify it with the wife.
My guess is that it's not so linear - you might not sell any copies at all of a command line thing, and a bunch once you get even a simple GUI on it.
Wrap a GUI around it and package the program as a single executable. I'd suggest $15. Asking for $20 seems like too much (to me), but I've been told that I have bad judgement in such matters. :)
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!").
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!").
Stick a dead-simple UI on it. Assume domain knowledge, not computer knowledge; this should be dead simple to an experienced handloader who barely knows how to use a computer. My dad would buy it, and probably shell out $50 if there's a reasonable demo so he can see what he's missing.
A friend of mine once wrote a shooting match scoring / ranking program for Palm PDAs. He had a hard time getting people to actually pay for it. But then again, he wasn't selling on the web.
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.
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.
Can I buy one?
And if there is other software that does what yours does, what is being charged for it?
The wife told me I can't spend any more time working on it, unless I can break even on web hosting, etc. So to clarify. I have to pay for web hosting, bandwidth, storage... as those things cost me money.
> The wife told me I can't spend any more time working on it, unless I can break even on web hosting, etc.
That's not what he asked, though.
That's not what he asked, though.
Seriously? That's your hang up? The cheapest web hosts are about $5/month. It ought to be easy to figure out how to make $5 with craigslist, tipjoy, temp labor firms, a lemonade stand, a garage sale, or doing discount handyman services for friends and family.
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.
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.
Yikes, you can sell nothing and break even. No, I actually sold an app for while, then took it down. People would still buy it occassionally, even though it was clearly stated that the app was discontinued.
?????????????? That's it?
Sign up for one of the millions of free blog/file hosts. Don't bother with a real domain name. Google pages seems nice.
Sign up for one of the millions of free blog/file hosts. Don't bother with a real domain name. Google pages seems nice.
if it is just the webhosting bill, you can certainly break even with adsense
I doubt that. It is not a webapp that the OP was asking about so the common pattern of usage would be download the software, use it, maybe come back and download an update. I don't think that adsense would be enough in this situation. I could be wrong though.
I was going to say $19.95 (which is a de facto standard for moderately priced installable software), but then I read your description below and I think it just won't sell.
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.
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.
[deleted](1)
I expect these kinds of apps - single purpose, but useful tools - TuneUp, or that Mac SSH filesystem thingy, etc, - to cost $15.
I would say $9.99 but $15 is good too. If I find something that genuinely helps me out, spending under $10 allows me to buy it without feeling guilty about spending money without asking the wife. Not that I need her permission, but in our relationship we clear most non-household purchases with each other if they cost more than $20. If I'm spending $10, that's like spending my lunch money. :)
I would also trial 19.99 to see if I could get more revenue. Experiment! Start high, run a sale a few weeks in and see if it makes a difference.
I'd suggest $9.99 with a "trial". Give them a few calculations for free and then shut it down until they register.
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!
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!
This is a great indication of the potential of a desktop "appstore". If it works for the iPhone, why not desktop?
It always has? 99% of all software sold is for the desktop.
Mostly sold through brick-and-mortar retailers, though.
If you could make it run on iPhone / iPod Touch then you have the GUI handled as well as an outlet for sales.
Oldie but goodie: http://www.joelonsoftware.com/articles/CamelsandRubberDuckie...
In my startup one of the mistakes we made early was pricing things too low.
In my startup one of the mistakes we made early was pricing things too low.
$19.95 ? or $24.95 ??
[deleted](1)