Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My humble suggestions to any service/product you introduce, even to beta testers, is to quote a price or an inkling of the upcoming pricing slabs. If there will be a free version with limited features, do mention that. For instance, I know Trello and Evernote will always have a free version which is good enough to a large extend and they promised that. I'm on Evernote Premium out of love though I still do not need the premium features. So is the same with Trello (few people were generous enough to sign-up through my links).

Without a price that I can calculate for continued future usage, I'm very reluctant to "get used-to" a particular app/service/product.

These days, if I like a product/service/site, and cannot find a price tag, I email the founders asking for an idea. Many do reply but it gets irritating that I have to do this quite often.

I do understand the marketing temptations and tricks of getting more users with "free trials". However, if your price in future is not affordable, then I'm going to be sad, irritated and may even hate you. Please don't let your customers hate you. It should be pretty OK to avoid customers from the beginning, who may not be ready to pay the price you quote than to promise them something and charge them another in future.



Thanks for bringing this up. I completely agree. Penflip is actually still in alpha, and wasn't quite ready to be shared with a larger audience. I was planning on posting HN with beta, which would include pricing.

Anyway, just so you know: the pricing model will be similar to github: free for open source / public projects, small monthly fee for private projects ($5+ a month depending on number of projects).


Unsolicited advice, but: I'm not sure that's the best business model for a tool aimed at writers. Github's model succeeded because there was already a thriving community of people contributing open-source work; with writing, most FOSS licenses don't make sense for the way that the content is consumed, and there isn't much of a pre-existing community built up around it that you can lean on. Most importantly, though, and unlike OSS, even people who publish in the public domain generally don't write drafts in it: they release articles and stories when they're finished.

I'd try to structure your business model more along the lines of behavior that people already have. Some ideas off the top of my head:

1. Notebooks. All writers are intimately familiar with the concept, and having separate notebooks is a useful organizational tool. First notebook's free, and you can pay for the rest.

2. Blogging. You can have one private working document at a time, and unlimited number of public blog posts. The private document is important — no one wants to publish half-finished. Want more working documents? Pay up.

3. Collaborators. You can collaborate with one person for free; if you want multiple collaborators, you have to pay.

I'm sure you can come up with others. My point just is: structure your company around your customers.


Good advice, thank you. I appreciate it.

On your first two points, this is not too far off from what GitHub does (and what I plan on doing) - the main difference is the nomenclature. You call them notebooks/blogs/documents, I call them projects, GitHub calls them repositories. The model is the same, though. FWIW, I'm calling them 'projects' because it's confusing to have multiple names for essentially the same thing.

The "first one's free" concept is interesting, and something I'm considering. However, I'm not entirely sure I agree with 'no one wants to publish half-finished' - Leanpub (http://www.leanpub.com) is built on this concept, and seems to be successful. Another argument is for open source and community-driven projects [1], which could be considered to be always in an unfinished state.

[1] https://github.com/HoTT/book




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: