Go Read: One Year with Money and App Engine

I would like to thank you for creating go read and making it open source, it's what I use as RSS reader, using my own free quota of App Engine. I hope I can contribute back some day.

  "30-day trial: This action cost me about 90% of my users. Many were angry and cursed at me on twitter. I agree that it is sad I did not say I was going to charge from the beginning, but I didn't know that I would be paying hundreds of dollars per month either."

Honestly I think the sense of entitlement nowadays is way too high, people use a product that is free and needed weeks or months of your own free time, and then complain about it when you change it.

If you decide to charge for it, you're a greedy bastard, instead if it's free, they say "if you aren't paying, you are the product". Other complain that the product doesn't work, when instead it's a case of PEBCAK. When it's not, it means you're going to say goodbye to a couple of night's sleep or a weekend or too, or maybe it's ONE feature away from being perfect (again).

...sometimes I hate people :(

Interesting writeup, thanks.

I'm a user and have been negatively impacted by the feed fetching optimizations - daily feeds are often a few days behind and come in bunches. Two examples:

- Penny Arcade updates its comics Monday, Wednesday, and Friday, always at 7:01AM UTC, and then news other times during the week. It's Wednesday at 4:25PM UTC - 9 hours after - and goread hasn't picked it up.

- Dinosaur Comics is updated weekdays. I'll eventually get all of them, but usually two or three at a time. For example, yesterday I marked all my feeds as read; today, I have entries from Monday and Tuesday, but not from Wednesday.

I had hoped that the move to the everyone-pays model would give you the resources (either developer or quota) to fix these issues, but they've gotten no better or maybe worse.

I haven't looked at what you're doing, but I believe Google Reader used pubsubhubbub where available to reduce/eliminate polling for many popular feeds.

I honestly didn't have a great experience with my last bug report, so I haven't tried again.

"Second, it is impossible to meet Google's terms of service with an RSS reader. They dictate that ads may not be shown along adult or copyrighted content. Determining that for external sources of data was not going to happen. I got a few emails about violations and added a system to prevent ads on certain feeds. But I was playing whack-a-mole and it would never end. Eventually I made a mistake and they banned my site. I gave up on ads at this point."

I've experienced this myself, and I'm hearing it more and more from others. Maybe this is a market need that is going unfulfilled.

Interesting that this article was written in March, about a week before google announced approximately %30 price-drops across its cloud offerings. I would have been interested to see the statistics for this year too, I don't think the chart tells us much about the sustained success (or otherwise) of your subscription model, due to only showing the 2 months after the introduction of subscriptions. The 2 months show rapid drop in income, has it stabilised this year?

I'm wondering, for the icons or other cacheable content, have you thought of using cloudflare or similar? What are your costs going to be this month, after getting onto the HN front page again?

After giving it a try, I noticed that this text is quite out of date now:

    We've just released! Read the blog post about it.

Congratulations on an income-generating project! That's an immense achievement. Perhaps the infrastructure cost is worth the headaches you spare yourself by being on GAE but have you looked at dedicated infrastructure from the likes of OVH/Hetzner (on both providers you can get ~2TB storage/64GB mem boxes for around $100/mo)? I moved all my projects to a single OVH box and it's been a champ. It does mean slightly more maintenance burden (ex you need to roll your own backup/restore plan). Perhaps it is a poor fit but that seems like a possible path to get those costs way under control

FWIW, original lack of discussion [0] and [1]...

[0]: https://news.ycombinator.com/item?id=7402393 [1]: https://news.ycombinator.com/item?id=7408089

Small bit of feedback: I'd love to see pricing for Goread before I go ahead and sign up. From the landing page, it's not even clear the project is active or that it costs any money.

That might be a good way to increase revenue.

I'm actually a little surprised it costs so much to run on app engine. Given that you've settled into a more predictable user model in terms of costs and probably growth, why not lower your costs by investing in dedicated server space or possibly reserved instances on AWS (unless there is a app engine equivalent).

Without knowing what your server load looks like, I would imagine you could save a couple hundred dollars a month in hosting, which would go right to your bottom line profit. A couple hundred dollars a month isn't huge, but at this point in your business that's say $2,400 a year. From the looks of it, that's at least 2-3 months worth of revenue or almost 5 months worth of profit.

I think it's at least worth considering with where your project is at right now.

Great read.

This is especially interesting to me. My side project http://www.longboxed.com was recently launched to a modicum of regular users (~300). My app runs on Heroku on the free tier with the 'Hobby Basic' level of the Heroku Postgres database. All told it costs me ~9 dollars a month. No big deal.

However, if I ever stepped the site up to another tier I'd be looking at ~50 bucks for the database and ~36 bucks for another process instance. These expenses can add up fast for a site that doesn't currently generate any money.

Anyway - it is nice to see examples of introducing a pay model into your app after it has launched.

Great stuff, Matt. I've always wanted to build something in the RSS space that could net me some extra cash. Write-ups like this let me know it's not a totally hopeless idea!

As for optimizing when to check for new feed items, I recently moved to the "moving average" strategy described here [1] for my personal feed reader [2]. Overall, more active feeds have really benefited from it while I still need to tweak the algorithm for less active feeds, I think.

Here's to another successful year for Go Read!

[1] http://www.rn.inf.tu-dresden.de/uploads/publikationen/feedpa...

[2] https://github.com/edavis/riverpy

I wonder if the author has costed out how much running this app would cost using a VPS provider like Linode or Digital Ocean? You can get a lot of resources for under $100 a month and the needs of most apps are pretty basic (file storage+db+web server). Given the memory requirements and speed of Go, it shouldn't take much hardware to serve a lot of requests with a few go instances behind nginx say.

I'm not convinced that being locked in to one cloud provider's services and APIs is healthy long term - it means you are locked in to that ecosystem and it's harder to consider alternatives, even if your needs are quite straightforward, so you can end up in a situation where you're paying hundreds of dollars a month for hosting when you don't need to be.

>Again, it's free software so I'm not sure what the problem is. I learned from this experience that some people will never pay, and some will. I'm not opposed to alienating people who won't support all of the time, effort, and money I put into this product.

It's always surprising to me when devs are surprised by outrage at the change/removal of a free product. There is a non-negligible cost for a user to research/choose/setup/learn a new tool. In this case, a feed reader has favorited articles, read/unread state of articles, etc. When you pull the rug out from users that have made that investment who now have to start over, they are going to be mad, regardless of what they paid.

Congrats Matt. Well done on testing various revenue options, instead of eating the costs just to be the "nice guy", only to have to shut it down eventually.

Ruben Gamez of Bidsketch had a similar story about switching from freemium to paid only -

http://www.softwarebyrob.com/2010/08/18/why-free-plans-dont-...

A long time user of your app, but from my own quota of appengine.

Thank you for such a lovely product. Someday I would like to contribute to your project(s) more.

I understand how app engine takes away a lot of pain wrt data storage, uptime, etc.

But, $600+ is a lot of money. You can get a good number of very decent servers for that kind of money.

If you are not afraid of managing your own data, I think hosting stuff on virtual servers is way more cost effective.

Nice article. Thanks for sharing!

btw: Lots of typos in the article, be sure to spell check !

Did you consider grandfathering existing users in?

Btw, what are some good options nowadays for [almost] free website launch? Until/(if ever) you get "big" of course...

> number of users is not a factor for Go Read

You could charge users a fee per feed proportional to server cost (e.g., frequency of posts) and inversely proportional to the number of subscribers.

* Unpopular/infrequent feeds (like my friends' blogs) would be free

* Popular/infrequent and unpopular/frequent feeds would be cheap, maybe $1/year/user/feed

* Popular/frequent feeds would cost more, maybe $10/year/user/feed

This way you can peg your income to an exact multiple of your costs.

Are there ways to get full articles of HN posts[1] through RSS?

[1]news.ycombinator.com/rss

From the article:

"A simple rule in computers is to make something run faster, have it do less work. I remember reading about how grep works quickly. Instead of splitting a file by lines and then searching for the string, it searches for the string, then finds the newlines on either side. Thus, if a file has no matches, it won't ever have to do the work for line splitting. Done the naive way, it would always split by line even if there was no match. Do less work."

Good observation, but I doubt if that's remotely even the reason why grep works quickly.