HN Explorer

Ask HN: A payment model similar to Google's App Engine?

3 points by sentinel ↗ HN
I'm building an application that will be able to register events from companies/bars/theaters etc. that are interested in exposing their events to a larger audience.

If a user finds an event interesting, he/she can favourite it or save it in their calendar. Once the user does this, it's a +1 count on the number of people/potential visitors for that event.

On the business side of things, I'm wondering if something like the GAE payment method would be a good idea.

That is: allowing the company that posts the event 20 'potential visitors' for free (a free quota), and for every other visitor above these 20, they would have to pay something like 5 cents/visitor. That virtual money would be coming from a balance in which they deposit money via paypal or something. When that deposit runs out, the event goes offline (is not shown to the users anymore).

Has anyone (well...except Google) tried this with any success in their business? Is it a good/bad idea? Any shortcomings? Do you have any suggestions or recommendations with regards to this plan of payment?

The reason I want to offer this quota is for small, independent events to be noticed for free...at least for the first 20 people.

Thanks!

3 comments

[ 4.3 ms ] story [ 20.3 ms ] thread
[dead] ndimopoulos
Interesting idea.

Frankly speaking I do not think that Google App Engine makes money. It saves money for people and with that it creates brand awareness for Google -> more money in the long run for them from advertising.

Your model can actually make money since you will allow a small number of people to use your service for free and promote themselves, while a larger event which is more likely to be funded better would pay you.

I also like the idea of the prepaid account. That would increase your liquidity since people will not use the whole amount of their credit.

Two things that I want to draw your attention to:

1. The points system might appeal more if you offer something in return to the users. Since you are beginning that will have a strain on your finances. I would therefore suggest spending some time with integration with existing websites such as Facebook and MySpace. A Facebook application can actually get you very far in brand recognition and use of your system. Later on you can encourage users to vote for their favorite events, for instance by raffling a couple of tickets. 2. Similar incentives can increase your traffic from the event organizer him/herself. If say you offer 4 cents a user if they invite 100 users and 3 cents a user if they invite 500 then that would be great for you :)

Wishing you the best of luck.

DeusExMachina
One shortcoming I see is that some dishonest person could target a competitor/company he dislikes by creating fake accounts and subscribing to events just to make these spend money.

I cannot asses if this is a model that could work, but you need to find a way to prevent abuses which could drive away customers.

sentinel
That's a good observation. And come to think of it, I did think of a way to disallow this type of activity, but not entirely.

Since the client app will run on a smartphone, the person using the phone will have to reinstall the application many times so that he could intentionally subscribe again and again to an event. So I guess one thing to do would be to register the mobile user with his mobile phone's unique identifier and not allow him to subscribe again to a previously subscribed-to event.

Otherwise he would just have to buy more phones, but I don't think that's a practical solution.