Quite possibly one of the best pricing pages I've seen in a while too.
Thanks for that. Now I have two sites getting pummeled at once.
It's not easy initially but things like http://www.ec2instances.info/ definitely help.
I agree strongly with this. I've had clients before who would refuse to make the move up from VPSs despite numerous advantages because the AWS product descriptions and prices were incomprehensible to them.
I'm as surprised as you. But I'm not arguing against math.
That's really interesting; how big was the difference and what do you think the source of the difference was?
* Less than 200,000 hits per day - $10 / month
* Less than 5 Million hits per day - $50 / month
* Over 5 Million hits per day - $300 / month
Huh, the blog post doesn't make it seem like he was 'initially hoping' to do that at all.
I guess it's good marketing to make it seem like you just "need some help to cover our expenses," and aren't actually making a profit?
But you're right. Sense prevailed, and I eventually started charging money in exchange for goods and services.
I am personally offended that someone is using "We had hoped to provide this for free but need to make expenses" as a marketing strategy to make more than expenses. When others really are asking for money just to cover expenses.
It may not matter to some people. There's nothing wrong with charging money for providing a service in order to make a good profit. But the marketing is obviously targeted towards those who it _does_ matter to, if it didn't matter to anyone, you wouldn't need to give the impression that you were _not_ charging money for providing a service in order to make a good profit.
I am in the minority of HN in having this reaction I guess?
I have no problem with him charging whatever price he can get for his service, that's business. I have a problem with marketing it as "We were initially hoping to provide this service free of charge. However, watching our bandwidth usage and server costs as people started using us, it quickly became apparent that we'd need some help to cover our expenses," if that's not true.
What's the reason to say this except marketing, because you think people are going to be more likely to pay if you say this? Does it not strongly imply that the guy is charging just enough to cover bandwidth and server costs? And is that true?
I have no problem with what he's charging, which seems a reasonable price, and really I don't care if it's reasonable or not, people can pay it or not, their choice, I have no problem with people charging prices that seem unreasonable to me, if they are successful at it anyway, good for them.
I have a problem with being misleading about your business model in order to get business, and in particular in pretending you are doing what some people _really are_ doing, but you are not, because you want to undeservedly get the good favor those people those people deservedly get.
I just don't like it in combination with the marketting suggesting he'd providing this as a public service only charging enough to pay server expenses, when that ain't true.
Looks like a great dev and a polished product.
"Cheap Bastard Plan" is both little too much slang, and unpleasant to look at if you are in a demo to show this service to upper management.
I am not saying that you should have a boring, enterprisey pricing page with formal words, in fact I really like what you did there with free plan. Just saying that you can rephrase it with little more easy-going words. :)
Great product, congrats!
I'd jack it to $750. To corporate, it's the exact same choice.
Do you worry about amazon releasing something to analyse the logs and killing your business? They just released Amazon QuickSight in beta and I think you will probably be able to import logs from their services. Of course the user will have to create the reports themselves but I guess your audience is tech savvy.
But yeah, the expectation is that they'll squash it dead any minute now. I'm hoping that the next thing I'm building will have replaced S3stat as an income stream by the time that happens.
So as I type this the votes are charging up the ranks (about 10 votes since I started typing this comment), so let me start off:
I can't possibly see how this is Amazon's fault. You're arguing that you offer a service for free (for a little while anyway), and that more people are taking you up on that because they have logs lying around, because Amazon has prompted them in the past to save these logs?
I mean, shouldn't this help your service?
a) now people can try it out because they already have logs and don't have to wait (which you've already identified was an issue), and
b) now people will end up with a bucket full of logs, think 'how can I analyse and use these logs', and go looking for a product like yours!
You've got it backwards. The OP is saying that due to AWS UI changes, it's more likely that user's will have logging enabled, thus showing more value for s3stat. This leads to more subscriptions. It's a positive piece, not a negative!
Then it could be used for static web site hosting just like S3 :(
See also: https://feedback.azure.com/forums/217298-storage/suggestions...
Mind if you could cover some broad details about how things are handled in the back end?
In broad terms, EC2 is the perfect fit for a service like this, that needs to run something like 100 hours of computing each day, but needs that all to happen during a 3 hour window before Europe wakes up in the morning. It's even more fun when something breaks and I get to spin up 200 machines in one go. For like ten dollars.
I use something like 8 different AWS services for various bits of the thing. Everything from computing to storage to queueing & mail. I even used them for payment at one point.
I'll try to get that writeup out the door.
It is unintuitive that you need to parse logs or pay $10 month to find out how much you are paying for each bucket.
But the blog started seeing a dozen requests per second before I could push the change live, and I've been in "nobody touch nothin'!" mode ever since.
But I snuck that CSS change in just now.
> I’d much prefer to keep those minutes for things like blowing off work for the day to go rock climbing because it’s sunny and I can do that because I run my own company. The less time I have to spend dealing with these customers, the better.
This doesn't really instill confidence in the level of post-purchase support I'd get if I were to buy in. I can easily empathize with the mentality and can even appreciate it if it's intended as humor, but all I see here is "I just want you to pay me."
So yeah, you might have to wait until the next day for a reply. But that reply will be to say that your issue has been fixed (by the guy who built the product) and that no further action is required on your part.
People seem to like that. (And a guy can only really climb hard a couple days a week without injury, so it's entirely possible you'll find me in front of the keyboard.)
As you add customers, you'll eventually be stretched thin as you try to cater to different needs (assuming that's your goal—it might not be!). Assuming you eventually bring on other technical folks, I'd argue that you'd want to prevent this same language and mentality from persisting as a part of company culture.
But again, your goal might only be to reach a certain size and live comfortably. If so, then you're probably fine. I suppose my qualm was more with the image conveyed by your language more than anything else.
That's OK for personal businesses. Not everything needs to be a billion dollar company.
> But again, your goal might only be to reach a certain size and live comfortably. If so, then you're probably fine. I suppose my qualm was more with the image conveyed by your language more than anything else.
> We're the sort of enterprise that is often termed a "lifestyle business" by people who feel that a software company should involve Venture Capital, sixty hour weeks, and "disrupting things". I'm sure we'd be doing all sorts of that if we were in the Bay Area, but we're not.
I like support like that. :)
I'll try to get back to you within a few months this time.
The conditions predicating the technical success of this tool aren't immutable.