Hacker News Reader

Comment by mrkurt | Hacker News Reader

This math isn't right, we bill based on total requests (not req/s capacity). It's $0.05 per thousand requests. So 86k/day * 30 days / 1000 * $0.05 means $129/mo.

Can we tweak the wording to clarify what we mean? We'll add examples, too. I really hate opaque pricing and wanted to make this as simple to understand as possible.

View on HN

This math _is_ right. 1000 requests/s is 86.4M requests per day. So for 1000 requests in a given second, that's $0.05 per second if you substitute the term. But to show you otherwise:

1000 req/s * 86400s * 30d / 1000 * 0.05 = 129600

It's only $129/mo if it's 0.05c and not $0.05, which is not what the website says.

Oh I see what you're saying. Then yes, your math is right, but our assumptions probably don't match. :)

1. This is our earliest launch. We're very expensive for 86mm requests per day right now. We have volume pricing planned but not rolled out. If you're interested, I'd suggest trying a low volume site to see how it feels and then get ahold of me to talk about volume pricing.

2. Our service is designed for "valuable" requests, not any ol' asset. API calls and pageviews are usually a good fit. Sustaining 1k "valuable" requests/s for a full month is pretty rare. I know you and other people on HN run that level of infrastructure, but our value prop for you won't be very high until we're more mature.

Sure but even at dozens or 100s of rps, the point where a loadbalancer really starts making sense, it's quite pricy. I think you just priced out $126 for a monthly average of one rps above. One.

This is an interesting point. I actually think our service makes sense from 0 requests, because we can (a) speed ssl stuff up immediately (and latency sucks at any volume) and (b) let people ship faster.

If you're building a SaaS that's doing ~2.6mm pageviews per month, you've probably saved enough time using our features that $126 is nothing. The economics for a free service or media property are different, but we'll be valuable for different reasons too (and possibly even have a different pricing model for stuff like that).

The pricing structure has similar problems at the low end. A small (2.6mm pageviews per month is tiny) SaaS would presumably have more than one request per page they want to fly-ify so once again fly becomes a big chunk of infrastructure costs. What's worse, it's linearly-really-expensive. A lot of services targeted at the low end tend to sell some sort of peace of mind - 'give us $100/mo for capacity you don't use but should you suddenly need it, we have you covered'. Whereas Fly is priced "it's expensive now but should you experience sudden growth we're really gonna ream you". And traffic growth doesn't necessarily mean revenue growth so the fact you were on the evening news or got really popular Malaysia might just mean a big bill. For a small service, Fly pricing is practically a DOS vector.

We should clarify this, but fly is best suited for the "valuable" requests, and we've been recommending that people put their static assets on a more traditional CDN.

We should _also_ document a policy on DOS stuff. We don't intend to run people out of money if they do get attacked. In fact, we have some ideas for middleware that would end requests early and not bill at all. Still, when we've done metered services in the past we were really generous with refunds / credits after bursts (which is basically what AWS et all do too).

I'd still say you need to take a hard look at your pricing. Lets assume we're talking about a pretty standard Rails site on Heroku without ridiculous traffic. Lets say 1500 requests per minute average (25/s).

25 * 86400 * 30 * 0.05 / 1000 = $3,240

I'm legitimately going to be spending 5-10x as much for my loadbalancer as I am 2 Heroku dynos and a reasonable Heroku Postgres instance.

All I can say is that I'd recommend discounting your price by 5-10x to put it in reach. You don't want to be the biggest line item in someone's budget, you'll be the first to go.

Back in the early days of FullContact, we charged a _lot_ per record for our Person API. After a lot of feedback at SXSW Interactive, we announced a 50x price cut. I'm pretty sure that's the only reason our API took off as a business. We optimized on volume and made it cheap to sustain thousands of requests a second. Five years later, that's paid off for us quite well.

Would it surprise you if I said we're testing pricing as part of our launch? I don't think anyone ever gets it right from the get go. :D

Hopefully if we get to be the biggest infrastructure charge in someone's budget, it'll be really hard to get rid of us.

5-10x discounts for volume probably aren't unreasonable.

Been in the startup game, totally understand. I'm presenting my view, which could be wrong but I figured you'd like my unfiltered feedback. Like I said before, we too had it wrong from the start and products we launched after weren't priced correctly either. It's a fine balance to price something just right to drive new customers, retain old, and maximize margins to ensure your venture succeeds (or can at least take another round to continue building).

Are you guys bootstrapped? Curious to hear more on that front. :)

:thumbsup:

We aren't bootstrapped, we raised a seed round. Turns out when you don't need money it's easy to get ...

I'm happy to give you all the gory details if you want to shoot me an email (mrkurt at gmail). I think we triggered the flamewar thing on HN so I can't respond here very fast.

> We aren't bootstrapped, we raised a seed round. Turns out when you don't need money it's easy to get ...

What? Why would you raise seed if you don't need it?

Old saying

Take money when you can get it, not when you need it.

A runway is not money that you don't need. That's my point.

This is probably worthy of a blog post, but!

We took investment for a few reasons. One is diversification, we can put our own money other places. More importantly, I think, is it's not weird when someone needs to get paid like it would be if we were personally funding the company.

And, honestly, we wanted to be able to move faster. We can try riskier things, be more generous with free plans, etc, etc.

Why would ants store food in the summer?

Because they will need it. Hence my point. Raising enough of a runway is just responsible. But raising money you don't need, isn't.

Pretty interesting - but doing some number crunching, Fly looks to be two orders of magnitude more expensive than enterprise cloudflare. Which does offer smart routing, load balancing and what not.

Hey, we're huge discord fans (we're mostly using it instead of Slack).

I'd love to find out more about what you all use for this stuff. I'm not shocked we're more than Enterprise Cloudflare, primarily because we don't have an Enterprise product just yet.

Yah sure - hit me up jh@<ourwebsitehere.com> (where ourwebsiteher is discordapp)

1k req/s to an API is not that uncommon at all. We were running at that rate way before we could even afford cloud services.

Can you explain what you mean by the math not being correct? I verified the previous poster's calculations. They do seem to be correct. Is this an issue with notation: $ vs. c?

This reminds me of Verizon .02 cents debacle from a while back.

Some sort of slider or something like CDN's have with scaling number of requests a day and the associated pricing would help. So like 10K a day, 100K a day, 250K etc.

Reply on news.ycombinator.com