Ask HN: anyone willing to contribute ideas for pricing for our startup? | Hacker News Reader

Ask HN: anyone willing to contribute ideas for pricing for our startup?

1 pointandrewstuart2 comments

Hi folks - we're coming out of beta soon and need to come up with pricing. trouble is I'm not sure how to price it. Is anyone willing to contribute ideas on pricing this service? Any input would be a help and much appreciated.

The service is an REST based API that converts documents to PDF and other formats, for example extracting text from documents.

The site is at http://www.pdfalchemy.com

I'm thinking that we should have subscription levels like:

$0 (free) per month to convert up to 100 documents per month

$x per month to convert up to 500 documents per month

$x per month to convert up to 1,500 documents per month

$x per month to convert up to 3,000 documents per month

$x per month to convert up to 10,000 documents per month

$x per month to convert up to more than 10,000 documents per month

I'd love some input from the HN community on what people think the prices per level should be, and also some input on the numbers of documents per month.

your input valued. thanks as

I have a project for a client that has a need for exactly this tool, but the pricing per month is a sticking issue. The problem is that the conversion to PDF is not tied to revenue for the project. And because it would be an unknown cost (they don't know how many word docs they will be getting), the client would not like it.

That said it could in theory be up to 5-10K documents a month in a year from now, but right now it is probably only 100-200 a month. Currently we are using an open source tool and having decent results. Not great, but acceptable so far. The second option is to require their users to provide only PDF, which is not ideal, but also acceptable.

It seems like this is a commodity product, so figure out what the cost is per document (or per gig of data.) Then add in some profit and that is your price. You can have larger profit on smaller plans and less profit on the larger plans. To do this, I would charge by data not document, since you can determine costs by data, not document.

Are there other value-adds besides # of documents? In the abstract, I'd like to see less granular pricing over the # of documents, instead charging more for value-adding benefits.

Reply on news.ycombinator.com