By all accounts, the RSS Reading space is ripe for disruption. As the dominant tool has died and left room for others to enter the space. As a heavy RSS consumer, I have tried many of the alternatives and settled on InoReader. That hasn’t been without its challenges though, as InoReader has struggled with issues in its very short five-month lifespan. When I recently published a story looking into the difficulties, InoReader’s creator, Yordan Yordanov, reached out by email to help explain some of his recent struggles and relate some of what it’s like to scale an application as intensive as an RSS Newsreader.

Yordan, thanks for answering some questions. Can you tell us a bit about you?

Yes. I am 29 years old, from Bulgaria, a small Eastern European country known for it’s yoghurt and football players (Stoichkov, Berbatov). My real name is Yordan Yordanov, but I am mostly known as Jacket. I am running a small (still) start-up company and I have a family and two children.

My profiles in the social networks:
– Facebook – https://www.facebook.com/Jacketbg
– Google – https://plus.google.com/109019495639295604418/posts
– LinkedIn – http://www.linkedin.com/profile/view?id=180972094

What motivated you to create an RSS reader back in April?

I was using Google Reader for the past 5 or 6 years to stay up to date with newest technologies and generic geeky stuff. As a LAMP developer I really needed to know what is the current bleeding edge. I loved it for it’s clean interface and it’s cloud nature – read everywhere on every device. I never really used the social part of it and I wasn’t a power user either. Just read about 30 subscriptions.

When the news of it’s retirement hit me I went shopping for a new reader and just couldn’t find anything that makes me happy. Nothing was even close, and (as I usually do) I tried to do something really simple myself (how hard can it be, right? A simple GUI, a database with a couple of tables and one background process to fetch new feeds… oh how wrong I was). I developed it at my spare time and in less than a month it had some finished outlook and a functional backend. I thought “There should be more people like me, why not share it with them?” and I published it in the Chrome Web store. And I knew people wanted social capabilities so I implemented it, but with an option to fully disable the social part if you want a “single player” experience.

You’ve mentioned that you created InoReader “from scratch”, how much of the tool is modelled on Google’s Reader?

Well it is totally inspired by it and this can be clearly seen. I tried to deviate a bit in some areas, but found that was a mistake, because eventually users insisted to have the same experience. Even the placement of the Star icon was a subject for dispute, because I had it on the right, and users just wanted in on the left of the article titles. So it is there now.

Some parts of your site depend on GoDaddy’s infrastructure; What has been your experience with them?

Only the domain name is registered and controlled via their service, but I am planning to transfer it soon. The only issue I had with them was the incident from June 23 when their DNS servers stopped responding for a couple of hours, but it is enough to consider using different service.

Can you give the readers a sense of how the company behind InoReader is taking shape? Do you feel InoReader is on the right track?

I can say we are doing good. When I started the company the goal was different, we have long experience in developing enterprise solutions and we already have quite a big customer using our software. But with InoReader I decided to take the opportunity to try something different and make it beyond a personal proof of concept project. I have now 3 people (excluding me) dedicated to InoReader. One community manager which relieved me from dealing with the huge amount of feedback (I was literally responding to emails from every possible place – work, home, bathroom, the playground, the zoo, etc..), one system administrator, who took the databases and servers in general to a new level and is still improving the architecture. And finally one Android developer, who is also a really experienced backend expert. He rewrote my first version of the feed pollers, so they can now fetch more than half a million feeds every hour without breaking a sweat.

I have still open positions and am in constant search of local specialists to enrich our team. I am trying to decouple myself as much as I can, because I am still a single point of failure. I am still the only one developing the web application and most of the backend and this is not at all optimal. Given the amount of positive feedback, we think we are on the right track. Future will tell if we are right or wrong.

On the development side of things, we know you use PHP and Apache. Can you give the readers a broad list of the kinds of technologies you using, and plan to utilize in the future?

Basically this comes from my background, because I started the project solely. I am a LAMP developer, so the project started this way – One Apache server, one MySQL database and everything was powered by PHP. When data volume started to grow I quickly realized that this will not be enough and introduced a MongoDB layer in the system for storing the contents of the articles (my mission is to make everything possible to not delete old data, just like Google did, but this is proving to be a hard task).

Then, of course, what good is a feed reader if it doesn’t allow you to search your own stuff? MySQL isn’t at all good in searching, so I decided to give Sphinx a go.

So now we have MySQL for the relational part, MongoDB for the raw storage and Sphinx for search. In the future we plan to make some huge changes to the MySQL layer, because the current architecture (mainly sharding) and to migrate some parts of the backend from PHP scripts to C++ compiled binaries for better performance. Also we are thinking about redundancy on all layers to further reduce or the risk of incidents.

I see that you’ve recently released an Android application. What are your mobile device plans?

We plan to develop our own mobile applications for the major mobile OSes – Android, iOS and WP8 (planned to be launched in that order). Our goal is to preserve the simple, but very productive way Google Reader behaved and then build on top of it without overloading the interface. We are also in communication with some of the current top developers about integration with their apps. We will release our API in about two weeks to the public. We are not planning to stay closed here. And last but not least we have a dedicated mobile web version since the beginning.

Can you give us a sense of the geographical distribution of InoReader’s users? How do you feel the time difference between your team and North America has impacted the scaling of InoReader?

I think no one will be surprised when I say that the top 3 territories are USA, China and Russia, The difference in number of users is really small between those. 4th place is Japan. We are feeling the time difference, because usually when North America wakes up, we are just finishing work and are going to our families. I personally felt that, because this was the time window when I received most of the feedback and I always wanted to respond fast to everyone, so my phone was like an extension to my hand (my wife’s words).

Can you share details about how you plan to monetize InoReader?

We will follow the Freemium model. This is the only certain thing right now. We are still doing a lot of calculations, but it is not our main focus right now. We still have a lot of work on the actual service before we start to roll out a paid model. We know there are still bugs and issues here and there, performance can be improved at some areas, and some users are experiencing network delays due to our location. We don’t want users to pay for unfinished stuff. It just doesn’t feel right.

InoReader is currently a free RSS Newsreader. InoReader also offers an Android application and a Google Reader compatible API.