Hacker News Reader

Comment by patio11 | Hacker News Reader

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.

View on HN

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.

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.

>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.

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.

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.)

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.)

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?

Reply on news.ycombinator.com