

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

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.<p>The service is an REST  based API that converts documents to PDF and other formats, for example extracting text from documents.<p>The site is at http://www.pdfalchemy.com<p>I'm thinking that we should have subscription levels like:<p>$0 (free) per month to convert up to 100 documents per month<p>$x per month to convert up to 500 documents per month<p>$x per month to convert up to 1,500 documents per month<p>$x per month to convert up to 3,000 documents per month<p>$x per month to convert up to 10,000 documents per month<p>$x per month to convert up to more than 10,000 documents per month<p>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.<p>your input valued.  thanks as
======
exline
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.

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

