Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we got to $1,000 in recurring revenue

blog.idonethis.com

Post reply on HN
Print view View original

51–60 of 73 posts

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

#51

Post by jmadsen »

louthy wrote: 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…

This is just cheap & short-sighted

At $50/month, it would take you a year to recover the cost of building it yourself on your company's dime. A time cost you should be spending on something to increase your company's revenue, instead of trying to save them $600 a year.

"I wouldn't pay 2 Starbuck's coffees per month, but I'd pay the price of a cheap cup at the gas station"

C'mon, man - everything on the internet isn't free.

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

#52

Post by patio11 »

clarky07 wrote: post #32
louthy wrote: 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…

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 whether your unit actually accomplishes business goals or not.

If you have 20 employees, many, many, MANY things with less certain value than this software cost you more than $100. Many of them are just costs of doing business which you ignore because $100 is chicken feed and moves no needle at the business.

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

#53

Post by lusr »

jacquesm wrote: post #44

Louthy in this thread is making a good case for the kind of user that you can afford to lose. If $5 per user does not cause some of your users to go away then you're too cheap. Scale it up an order of magnitude, or even two, watch your competition like a hawk and make sure that you make you users happy , never mind about them resenting to pay. The way to offset that is not to lower your price but to give more for the…

It's not really a "Show HN", though is it? It's an paid-for extension of an existing product. In that vein, while an informative post I did find the following statement a bit disingenuous:

"As Paul Buchheit, creator of Gmail and partner at Y Combinator, says, the correct order of operations is to “sell before you build.” When you launch, you want a whole list of people that you can tell to buy it. But more than that, you want to ensure that you’re investing all that time building something that people want to buy."

As far as I can tell, they built a product for 40,000 people over a certain period of time without generating a cent in profit or knowing in advance that any of those people would ever consider paying from the product. While some users did claim they wanted a team version they would pay for, this was only after the base product was built without knowing people would pay for it.

This bugs me a bit because I'm working on a project where I'd love to be able to sell before I build, as it's obviously a very sound principle, but in practice I just can't see how to go about it and I was hoping to learn something new from this post.

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

#54

Post by e12e »

First: congratulations!

Second: you say that: "Your privacy and security is our top priority. We take all reasonable precautions to keep your data safe and secure."

Does that mean that you support s/mime and gpg for the emails you send and receive?

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

#55

Post by JRFuentes7 »

adamrubin wrote: post #41
tghw wrote: post #35

Earlier quoted context omitted.

Your time must not be worth very much if you're really considering rolling your own. How long will it take you? A day? You might think so, but no. A weekend? Possibly, but you won't handle all of the corner cases. A week? Getting closer. How much would you pay yourself for a week of work?

I had the idea to build something very similar, but hoped to find a pre-existing solution. When I found idonethis, I found the cost prohibitive, so I built it myself. It took me about a week, so that's fair, but that's to rebuild not just the core functionality, but also the multi-tenant SaaS part. I have a 50 person team. So, I would've paid $250/mo, or $3k/year. So, I really invested $2k to develop my own version,…

I love that you displayed your "innovation accounting" here. I'm wondering, how do you account for ongoing cost for maintaining/updating the software? I've never seen software that didn't require some TLC over time...

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

#56

Post by mattmanser »

lusr wrote: post #53
jacquesm wrote: post #44

Louthy in this thread is making a good case for the kind of user that you can afford to lose. If $5 per user does not cause some of your users to go away then you're too cheap. Scale it up an order of magnitude, or even two, watch your competition like a hawk and make sure that you make you users happy , never mind about them resenting to pay. The way to offset that is not to lower your price but to give more for the…

It's not really a "Show HN", though is it? It's an paid-for extension of an existing product. In that vein, while an informative post I did find the following statement a bit disingenuous: "As Paul Buchheit, creator of Gmail and partner at Y Combinator, says, the correct order of operations is to “sell before you build.” When you launch, you want a whole list of people that you can tell to buy it. But more than that,…

That comment jarred with me too, in reality what they did is the total antithesis of what Paul's quote embodies.

There are a few options for seeing if people will buy before you build. The often quoted one here (and it's also used in the Lean Startup as an example) is have a sales site, have a 'buy now button', but go through to a 'we're currently in beta, email me when it's ready'.

Then buy google ads or whatever your sales pipeline is and see if people click 'buy now'. If no-one does, you've got a problem.

If you've got a big ticket item, you can do something similar but be upfront that it's not built. Talk to clients, see if they want what you're thinking of making and suggest a price to see if they say yes. Again, if you can't find anyone to say yes, you've got a problem.

And for some projects, Kickstarter is another obvious method.

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

#57

Post by jacquesm »

mattmanser wrote: post #56
lusr wrote: post #53

Earlier quoted context omitted.

It's not really a "Show HN", though is it? It's an paid-for extension of an existing product. In that vein, while an informative post I did find the following statement a bit disingenuous: "As Paul Buchheit, creator of Gmail and partner at Y Combinator, says, the correct order of operations is to “sell before you build.” When you launch, you want a whole list of people that you can tell to buy it. But more than that,…

That comment jarred with me too, in reality what they did is the total antithesis of what Paul's quote embodies. There are a few options for seeing if people will buy before you build. The often quoted one here (and it's also used in the Lean Startup as an example) is have a sales site, have a 'buy now button', but go through to a 'we're currently in beta, email me when it's ready'. Then buy google ads or whatever yo…

Sell before you build: you go through what you could automate by doing it by hand. Automation is optional. If you actually sell automation then that is of course impossible but if you sell a product that you could create by hand just as well as through a computer program then you can sell right away.

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

#58

Post by schnaars »

lusr wrote: post #53
jacquesm wrote: post #44

Louthy in this thread is making a good case for the kind of user that you can afford to lose. If $5 per user does not cause some of your users to go away then you're too cheap. Scale it up an order of magnitude, or even two, watch your competition like a hawk and make sure that you make you users happy , never mind about them resenting to pay. The way to offset that is not to lower your price but to give more for the…

It's not really a "Show HN", though is it? It's an paid-for extension of an existing product. In that vein, while an informative post I did find the following statement a bit disingenuous: "As Paul Buchheit, creator of Gmail and partner at Y Combinator, says, the correct order of operations is to “sell before you build.” When you launch, you want a whole list of people that you can tell to buy it. But more than that,…

When we launched our company, we spent quite a bit of time identifying, based on the concept, who are the top 100-companies that we would like to do business with, who in the organization would buy this and how do we get to that person.

From there, we cold called / emailed like maniacs - 'here is what we are working on, here is the problem it will solve, here is why you need it, can we have 20-minutes of time to walk you through this?' We leveraged every possible network connection that we had.

When we got people on the phone, we actually showed them mocks of what their site would look like with our platform (lots of Photoshop). Explained that about how we wanted to get them in a beta program, and how much would they pay?

It was a ton of hustle, but we had 10-customers when we launched that were generating a little bit of revenue and willing to give us quotes in the press or get on stage at events.

It is more of a larger, enterprise sale, so it won't work for all companies, but we were essentially selling something that we were building in parallel and wouldn't accept free for an answer.

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

#59

Post by icefox »

lusr wrote: post #53
jacquesm wrote: post #44

Louthy in this thread is making a good case for the kind of user that you can afford to lose. If $5 per user does not cause some of your users to go away then you're too cheap. Scale it up an order of magnitude, or even two, watch your competition like a hawk and make sure that you make you users happy , never mind about them resenting to pay. The way to offset that is not to lower your price but to give more for the…

It's not really a "Show HN", though is it? It's an paid-for extension of an existing product. In that vein, while an informative post I did find the following statement a bit disingenuous: "As Paul Buchheit, creator of Gmail and partner at Y Combinator, says, the correct order of operations is to “sell before you build.” When you launch, you want a whole list of people that you can tell to buy it. But more than that,…

So whats your products?

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

#60

Post by alanctgardner2 »

rgrieselhuber wrote: post #34
asanwal wrote: 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.

If I were him, I wouldn't worry about 1 customer saying they'll build their own. My coworker (a PM, no less) decided, rather than Solr or ElasticSearch, to write his own search engine for a work project. He did it, and it obviously took 10 times longer than estimated and cost way more than was necessary. There will always be a proportion of customers who want it cheaper, but that doesn't mean you're priced wrong: it means they're not measuring value accurately.

For a good engineer, 600 dollars gets you something between 10 and 20 hours of work. To produce a polished project, start to finish, that's not going to happen.

Post reply on HN