Hacker News new | past | comments | ask | show | jobs | submit login

Very cool, but also a bit misleading.. I was wondering how the hell wub machine actually makes 900$/month, so I read it.

> Record high was $850/mo, record low was $40, with the average month bringing in around $300. Certainly not quit-my-job money, but it helps.

Posting the all-time high instead of the average is a bit off-putting imho, considering it's supposed to represent "paychecks." This is more like getting lucky once. Anyways, haven't read the rest of the stories, and I think it's pretty inspirational. I'd just appreciate more honest revenue reporting on the front page. (It actually says $900/mo, not just $900, so it's not like I'm reading this ambiguously..)

Edit: On second thought, it's not clear to me from the description whether he means that it made $900/mo for some kind of long streak or just one month.




I came here just to post the same comment. I hate to be negative because this site seems very interesting and I love the content, but what I would say is that I don't think there is any need to embellish the numbers for the audience this content will attract. I would have read the article had it said $300/month or $900/month all the same, except now I trust the overall site less than I would have had it been honest.


Thanks for questioning the honesty of the site. Your comment is truly productive and, sadly, at home against all the jaded (and envious) comments here on HN.


Sorry, I'm rounding peak monthly revenue to the nearest $100, which works well for dollar amounts in the thousands (e.g. $2.2k) but not in the hundreds. Also, in the future, I'll definitely include both peak and average revenue numbers.


The problem isn't rounding, it's that you report peak instead of average.


Yep, I agree! Will include peak and average in the future.


Cool ;)

Edit: I'll just note that considering the presence of peaks, probably median would be a better indicator than average. Hell, a whole distribution would be pretty informative lol, but that's probably too much info..


I mean, mean is better than median in that if you multiply it by time then it gives you the sum.

But mean over what period? It's a bit complex.

I think that probably @csallen was using "peak" because some of the projects had since gone defunct and he wanted to count them. Although I think in such cases it would make sense to do an average of the best year or something like that.

For projects like mine (https://complice.co/) which are still growing, "peak" is also weird, because it suggests that... I'm not still growing? I'm not even sure. At any rate, it doesn't make sense to use my average over the last year if my average over the next year is going to be twice as much. Better is probably just the total of my active subscriptions.


Moving average as an annual or monthly run rate is a decent way to express it.


Oh yeah, true.. I just meant to be less sensitive to outliers but you make a good point.


Sparklines!


Needs more D3..


@csallen, I might have an easy solution for this, DM me on Twitter


Similar thoughts here. However, the one project Apex Ping, says he's making $600/m but not cash flow positive yet. I'm confused as to how that's even possible. I can run that service on a handful of VM's for ~$60/m.

He says he's using Lamda, perhaps he should rethink that decision if his overhead is really that high.


There's a lot more to it than that, and I'm currently supporting ~2000 users on the free plan as well (though I'm phasing that plan out).

Ping is running in 7 regions, has an Elasticsearch cluster for logging, another for the check data itself, thousands of checks running each minute and thousands of alerts running each minute. RDS for the primary store, SES for emails, EC2 for hosting the app itself. Add on extra services such as Baremetrics and these things add up quickly. Run 7 EC2 nodes and you're already well over $250, not to mention the loads in each region are different.

Lambda's pricing is indeed not competitive with VMs right now, but that will go down with FaaS becoming wildly available from other providers. The more important thing to me is that it's close to zero maintenance, no bastions, no AMIs, no provisioning, no third-party monitoring, etc.

If you've ever worked with Elasticsearch you'd also know that it requires a pretty substantial set of resources to function well. I'm happy to over-provision for the beginning if it means providing a better experience. Nothing would be worse than under-provisioning IMO.


>(though I'm phasing that plan out).

Would you recomend starting something with a free tier and phasing it out if it's not working over charging up front from the beginning?

I can see pros/cons to both sides.


I've been looking into myself recently.

From successful bootstrappers in B2B, nearly 100% of the advice that I've gotten is to start without free and add it later as a lead-gen mechanism if it fits your business. Early on customer acquisition is a slog and generally relies on 1:1 conversations often with a pre-existing relationship (in-network). Hopefully feedback from these people help you get close enough to product market fit that outsiders will consider using the product. From there it's a marketing and lead nurturing game where freemium may make sense.

Advice for B2C would be quite different.


I think it depends greatly on the cost of supporting the free plans, mine just went a little out of control, I was getting ~100 or more users per day. If it was really cheap to support them it might be worth the marketing side of things. And of course for VC backed companies this still looks more attractive than not having the free users at all.


Could be that most customers are on the free tier and he has multi AZ deployments plus other AWS services (data, queues, etc).

Typically base costs are higher when you design for scale vs when you don't. And marginal costs are lower when you design for scale vs when you don't.


There is no free tier. There's a trial.

And yes, that's obviously a concern, but you can design for profit first and refine for scale. It wouldn't be very difficult to put some of those things in a VM to start and then move them to lambda once breaking even is no longer an issue.


Responded above, there was a free plan initially.




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: