Live data from Hacker News

How we got to $1,000 in recurring revenue

blog.idonethis.com

61–70 of 73 posts

Re: How we got to $1,000 in recurring revenue

#61
post #18

Earlier quoted context omitted.

Dear iDoneThis team - do NOT lower your prices [1]. As a fellow subscription revenue biz, we've found that lower priced plans invite customers whose support requirements are much greater. And you won't make it up in volume. Real businesses that value their time will spent $50/month for a service that saves them time without thinking twice. Your early traction proves this out. The graphic you had in your post about de…

Couldn't agree more. With all due respect to louthy, making a decision to lower your prices based on the notion that a customer finds it to be a good use of their time to save $600 / year to build a copy of your service indicates that the amount of time it takes him to build it is worth less than $600. That might not be a great target market.

'Less than $600 a year' is different to 'less than $600'. If you plan to use it for 4 years (assuming team size remains constant), that's a potential saving of $2400.

Re: How we got to $1,000 in recurring revenue

#62
post #52

Earlier quoted context omitted.

I think a much better solution would be to not charge per user, and to make it tiered. This is the type of thing that could be useful to teams of different sizes, but it doesn't add more value for more users really. Paying $25 a month for 5 users seems ok. Paying $100 a month for 20 users seems absurd. Just do 3 tiers for like 1-5, 5-20, > 20 users on the order of $19, $29, $49 or something.

If you have twenty users for this system, it is likely that "you" pay more than $50,000 every other Friday . (Substantially more if they're techies.) I say "you" in scare quotes because much like software payroll just comes out of a budget and isn't "your" money -- spend it or don't spend it, your call, but either way it isn't in your pocket. Your personal financial situation is influenced in a much sharper degree by…

Now that is a good point. I still think tiered pricing is a better fit, but perhaps he can make the tiers higher.

Re: How we got to $1,000 in recurring revenue

#63
post #18

Earlier quoted context omitted.

Dear iDoneThis team - do NOT lower your prices [1]. As a fellow subscription revenue biz, we've found that lower priced plans invite customers whose support requirements are much greater. And you won't make it up in volume. Real businesses that value their time will spent $50/month for a service that saves them time without thinking twice. Your early traction proves this out. The graphic you had in your post about de…

> As a fellow subscription revenue biz... I think it's hard to group all "subscription services" into the same bucket. Selling proprietary data in the financial services market (like CB Insights) is very different from selling a simple tool (like iDoneThis). Also, it should be noted that price is just one component of a pricing model . If you don't look at how you charge, and only consider how much you charge, chance…

If your company has 10 teams of 10 people, your most important action is not saving $500 a month. You're (hopefully) earning a proportionally higher amount for your 100 people and you should continue to focus on that. If the software stack helps, don't fiddle with it to save a few bucks.

The challenge for iDoneThis is not to make it cheaper per user, it's to re-invest the highish costs in order to beat the competitor who is charging 50c per user. Make iDoneThis better at managing the ever-growing complexities of syncing information when you have 100/1000/10k staff members and you have no damned idea what they're doing.

Especially because quite a few hackers are thinking "you know, I could make that app and sell it for a few bucks less." Don't race them to the bottom, because Twitter is at the bottom at $0p/m.

Re: How we got to $1,000 in recurring revenue

#64
post #52

Earlier quoted context omitted.

I think a much better solution would be to not charge per user, and to make it tiered. This is the type of thing that could be useful to teams of different sizes, but it doesn't add more value for more users really. Paying $25 a month for 5 users seems ok. Paying $100 a month for 20 users seems absurd. Just do 3 tiers for like 1-5, 5-20, > 20 users on the order of $19, $29, $49 or something.

If you have twenty users for this system, it is likely that "you" pay more than $50,000 every other Friday . (Substantially more if they're techies.) I say "you" in scare quotes because much like software payroll just comes out of a budget and isn't "your" money -- spend it or don't spend it, your call, but either way it isn't in your pocket. Your personal financial situation is influenced in a much sharper degree by…

> If you have 20 employees, many, many, MANY things with less certain value than this software cost you more than $100.

It seems like you're arguing that if you have 20 employees, you're probably wasting more than $100/month on other products and services, so spending another $100/month on iDoneThis isn't a big deal.

You might be right in certain cases. Some companies have tighter financial controls and are more thoughtful about managing expenses than others. But as valuable as it might be, iDoneThis is very limited in scope and, perhaps more importantly, is not a "checklist cost" that companies (justified or not) expect to have each month. As such, I think it's very precarious for iDoneThis to depend on the old "companies waste more money on other stuff" non-value proposition.

As I noted in another comment, I think it would be wise for iDoneThis to reconsider its pricing model as $5/user/month seems very likely to create agita as the number of users scales. As an example, consider that a Silver Github plan costs $50/month, and can easily support many companies with a 20 person development team.

Re: How we got to $1,000 in recurring revenue

#67

Earlier quoted context omitted.

> As a fellow subscription revenue biz... I think it's hard to group all "subscription services" into the same bucket. Selling proprietary data in the financial services market (like CB Insights) is very different from selling a simple tool (like iDoneThis). Also, it should be noted that price is just one component of a pricing model . If you don't look at how you charge, and only consider how much you charge, chance…

If your company has 10 teams of 10 people, your most important action is not saving $500 a month. You're (hopefully) earning a proportionally higher amount for your 100 people and you should continue to focus on that. If the software stack helps, don't fiddle with it to save a few bucks. The challenge for iDoneThis is not to make it cheaper per user, it's to re-invest the highish costs in order to beat the competitor…

> If your company has 10 teams of 10 people, your most important action is not saving $500 a month. You're (hopefully) earning a proportionally higher amount for your 100 people and you should continue to focus on that. If the software stack helps, don't fiddle with it to save a few bucks.

This type of thinking is prevalent on HN, but it's not always realistic. Most companies of a certain size have financial controls, and even if $500/month is not a lot of money in a relative sense, the number of $500/month line items for nice-to-have, this-helps-a-little products and services is reasonably limited.

Getting a budget for something that isn't in a "checklist cost" category can be a real headache, every vendor relationship has overhead, and instituting a new SaaS for 100 people (and getting them to actually use it) may have its own costs (staff time, etc.).

> Make iDoneThis better at managing the ever-growing complexities of syncing information when you have 100/1000/10k staff members and you have no damned idea what they're doing.

That's a fundamentally different product than what iDoneThis has today. To support development of that product, it will need substantially more than $1,000/month in recurring revenue, or it will need additional funding.

> Especially because quite a few hackers are thinking "you know, I could make that app and sell it for a few bucks less." Don't race them to the bottom, because Twitter is at the bottom at $0p/m.

If you build a business around a simple concept that requires limited functionality, you can refuse to engage in a race to the bottom, but it doesn't change the fact that you will almost certainly be undercut if others see a worthwhile opportunity.

In other words, iDoneThis can keep its $5/user/month price point, but if this is an appealing enough concept, it will have competition, and cheaper competition, before it ever obtains enough revenue to "re-invest the highish costs" as you have suggested.

Re: How we got to $1,000 in recurring revenue

#69
post #48

I wonder, with a product as simple as theirs: how do they differentiate from clones? I mean, they're targeting developers and teams with a useful service, but also a service so simple that most developers could create a minimal clone that performs their core feature in a few hours. Either their product needs to have really neat integration into other tools (like time tracking, project planning, etc) or they need to h…

The domain is pretty unique and memorable.

Re: How we got to $1,000 in recurring revenue

#70
post #18
post #11

Please take this as constructive: I pay for your system for a team of about 10 people. It works and it's been useful to us - but as soon as I get some free time I'm very likely going to roll my own, because I slightly resent the $5 per user per month price-tag for such a simple service; I think it's pretty expensive for the features compared to other single-purpose cloud tools. I'm not asking for more features, becau…

Dear iDoneThis team - do NOT lower your prices [1]. As a fellow subscription revenue biz, we've found that lower priced plans invite customers whose support requirements are much greater. And you won't make it up in volume. Real businesses that value their time will spent $50/month for a service that saves them time without thinking twice. Your early traction proves this out. The graphic you had in your post about de…

>As a fellow subscription revenue biz, we've found that lower priced plans invite customers whose support requirements are much greater.

This has been my experience, too. The customers who consume the most support resources are almost always on the lowest cost plan.

Post reply on HN