Ask HN: Choosing a pricing model | Hacker News Reader

Ask HN: Choosing a pricing model

2 pointscodegenerator6 comments

Hi all,

   here's the context of my question for you...

--- What I am doing ---

I am doing a code generator to help users kickstart java application.

Using a database schema we generate all the standard technical layers (maven/bean/dao/spring/hibernate/springmvc etc).

This is pretty standard, but what's different ?

  We do it online. It's our purple's cow touch.
  We focus on the integration within frameworks/layers which is a real pain to many.

--- How does it work ? ---

1. You reverse engineer your database using a tool available on our site

3. You upload the extracted metadata to our site

4. The site generates the source for a working CRUD java application

  With best of breed technologies and best practices.
  With *no dependency* on my service.

 5. You download the source code and start your own project using it

  You are on you own, no need for our service anymore.
  However you may want to use the tool again when
    . You add a new table/relation modify column (and do not want to update manually the source code)
    . You want a new module available (hibernate search integration, new web layer)

--- My questions for you ---

1. How do you price a code generation tool ?

  Would you charge per generation ?
  Per month ?
  Per user ?
  Per database schema ?
  Per number of tables ?

2. Would you give a trial version ? If so how ?

  By removing generated unit tests ?
  By forcing the package name ?
  By adding a specific header in the source files ?

3. Would you forget the online approach and settle with

  A maven plugin ?
  An eclipse plugin ?
  A standalone application like codesmith ?
  How you would protect it ?

Thanks for your attention

"we focus on the "? You left something out.

A better approach to figuring out how to charge for this is:

"what workflow do I anticipate my likely customers will have, and how would this product integrate into that workflow?"

You should also look at what other products are in this space, if any, and see how they price themselves.

All that said:

I'm not sure selling this as a service is the right approach.

You could set yourself up as a specialized consultancy (give us your tired old schemas, we give you a shiny new data-access layer using your choice of the current best-of-breed technologies), and just keep your code generator as your secret sauce.

Then you market your consultancy to various outsourcing shops, offering to take the initial persistence layer coding off of their hands for their new projects. You can turn around better quality code for this stuff, faster, than any of the sweatshop operations, and you're cost-competitive with the sweatshops, too.

I know the dream is to set up a service, let it run, then sit back and collect the checks, but the consultancy route might be an easier route to monetizing this.

Otherwise, I would attempt to negotiate big-dollar site licenses with large outsourcing firms, who probably stand to benefit the most from this technology (b/c they are the ones who most often are given a legacy database and asked to build systems on top of it).

If you go that route, being available over the web isn't much of a selling point.

For a trial versions, making an unlimited use trial for N months (N = 1, 2, or 3) available after a phone call works:

* the phone call step slows things down, but makes it much more difficult to "farm" an infinite # of free trials (!)

* since the primary value-add for this service is at the start of a new project, and since the typical large outsourcing firm has new projects starting all the time, a short-ish trial doesn't run much risk of giving the customer everything they'd want from the full product (b/c it only helps them with projects that were getting started in those months)

(!) If you go this route, don't hard-code a time limit, but do set up some automated emails to remind you when a trial is coming close to wrapping up. It's helpful as a sales thing to be able to extend the trial a week or two (or, at least, it's terrible from a customer's standpoint if the trial cuts off hard right in the middle of something).

Going after the "typical large outsourcing firm" seems too much for us: we suck at sales.

Internet is more our cup of tea, and easier to market I think, and yes I have to admit the dream to set up a service, let it run, then sit back and collect the checks it very tempting :)

Any hint on the pricing model you would see for the online service ?

If I were you I'd avoid anything overly complicated.

A lot of potential customers are going to balk if they have to put any work into figuring out how much your service is going to cost (eg: if it was based on some formula involving the table count and the column count(s)).

Sometimes a clever and innovative pricing scheme works well, but a lot of times customers shy away from anything they're not already used to. Keep it simple to figure out what this is going to cost.

If I were you I'd split your offerings into three tiers, basic, medium, and enterprise, and then sell them on a subscription basis. When you subscribe to a tier, you get unlimited use of that tier's offerings (!).

Basic would be aimed at projects a small ISV would tackle; probably put in some limit on the model complexity, or omit some of the crown jewels.

Medium would be aimed at larger projects; relax the limits on model complexity and omit fewer of the crown jewels.

Enterprise would be aimed at "enterprise" stuff, would have essentially no limits and would include the crown jewels, if you have any.

Candidate prices: 99/yr, 999/yr, 9999+/yr, but you should do more research to home in on something.

I suggest yearly subscriptions b/c it's more money upfront, it puts less mental strain on a potential purchaser, and the larger #s make you look more serious.

About the "more serious": $99 is cheap, but a believable price for "serious software". The equivalent monthly rate is ~$8.50/month, which is hard to take seriously as being "serious software".

I want to reiterate that you'll probably have better luck monetizing this in some different way; no harm in trying the service route first, if that's what you want to do.

Even as a service, though, you guys need to pound on some doors and do some interviews to figure out which features are wanted by what potential customers, and why; this will help you refine your offerings, get a better handle on the right price(s), and figure out where best to draw the lines between tiers.

(!) If you do offer unlimited use within a tier make sure your terms of service prohibit resale of the service itself. You'll also need to plan on building a monitoring infrastructure to alert you to "suspicious use" (eg: high volume on an account, or a large # of distinct ips using a particular set of credentials).

I've just written an article on how best to price an application:

http://blog.stormideas.com/archive/2009/01/07/pricing-your-w...

I hope it's of use to you!

Bob

Why is this a web app? For many companies even letting your service see the database metadata is not going to be viable. i.e. you're excluding the potential customers with the most money.

I understand this point, that's why there the third question :)

Would you create A maven plugin ? An eclipse plugin ? A standalone application like codesmith ? How you would protect it ?

What pricing model would you choose ?

Reply on news.ycombinator.com