Reducing Churn for an App That I Love by Talking to Customers

Hello! What's your background, and what are you working on?

Hi, my name is Ivan Grishaev. I'm a programmer from the small tech-hub Voronezh in Russia. I work remotely with European customers. I'm a fan of functional programming, I enjoy coding in Lisp and Haskell, and I use Clojure every day for business purposes.

I'd like to introduce Queryfeed. It's my pet project that I've been running for five years. Queryfeed is a web application that lets people search for something in Twitter, Facebook, Google, and Instagram whilst maintaining their anonymity (i.e. not having to create an account and log in). Users receive their results in an RSS format, which allows them to easily process the data or subscribe to it using an RSS client.

People use Queryfeed because it deals with the limits that every social network has. It is not so easy to batch fetch data from social networks. Even you if are a programmer, you'll need to read the API documentation, write code, and test it. In Queryfeed, you just input your query term without registration and have the result composed in a useful format that can be processed by lots of programs, thereby saving you time and money.

The majority of requests Queryfeed handles are machine-generated. There are scripts, tools and bots that need to fetch data from Twitter. They teach neural networks, find trends, etc. Every day my server processes about 6 million requests generated by programs.

Queryfeed's commercial subscription costs $4.99 per month, and provides benefits such as shorter cache time and more data in the results. At the moment, I'm earning about $150 per month via PayPal.

What motivated you to get started with Queryfeed?

Initially, Queryfeed was just a toy Python script that grabbed data from Twitter. I wrote it because our system administrator blocked access to every social network. I'm not a fan of Twitter or Facebook and never was, it was a fun challenge to break the rules and read Twitter using my script and RSS client.

Personally, I like the idea of spreading information without limitations. Social networks keep huge amounts of data that they use commercially. I believe any fragment of information on the Internet should be indexed and available to everyone on demand. And although my tool can only highlight a tiny part of that data, some movement in that direction is good.

I knew some people who were interested in fetching data from Twitter: journalists, SEO guys, programmers training their AIs, etc. On the one hand, Twitter is just a huge trash bin full of random thoughts. On the other hand, it's our modern history. Reading millions of tweets, we can discover hidden trends and find out more about ourselves.

As far as I'm aware, nobody's created a web application like Queryfeed, because it's difficult to support and monetize. I've only come across one service besides mine that provides the same capabilities, but it has far fewer options.

Once you've got a product, add a PayPal/Stripe button as soon as possible. Sell your product immediately.


I'm sure the idea behind Queryfeed is not really fantastic. It relies completey on third-party businesses (Twitter and Facebook). One day they can announce a new API and shut down the old ones, preventing me from communicating with them. And, speaking honestly, RSS is for geeks, not a wide audience.

Several times I've thought that it's stupid to support Queryfeed. Maybe I should just stop the service and publish the code on Github? But then I found that people need it. For example, when the serve used to have downtime, people would email me asking, "What happened?" and "Please tell me are you going to support it?"

So I decided to run it forever, no matter how little I'm paid. I still cannot afford a red Ferrari, but it makes enough money to pay for hosting, so I'll let it continue whatever happens.

I was thinking about adding more and more data sources to Queryfeed to make it some kind of a search machine. I'm still not sure how it should work, but I try to imagine it from time to time. I've also considered adding popular Russian network Vkontakte as a data source, but I gave up after dealing with their API limitations.

Currently, I'm the only one person supporting Queryfeed.

What went into building the initial product?

From the beginning, I decided to make my service as simple as possible: just an input field like Google has on its main page. Previously, I worked on another web application, but I didn't have a strict roadmap, and so I'd rewrite everything from scratch every week. In the end, I gave up after failing to deal with the growing complexity of the product.

I spent my own time developing Queryfeed: one hour in the morning, and sometimes more at night. I had to keep up with my daily duties — my job and spending my time with family — so I moved slowly but regularly.

I turned my script into a web application, bought a domain and published the service on Google App Engine, a cloud service that was popular in those days. To attract people and get some satisfaction, I published a post on a famous Russian technical site Habrahabr. That was almost five years ago, and that became Queryfeed's birthday.

As for technical detailsm, I initially used the Python programming language to create the first version of the script. Then I wrapped it with a Flask framework to made a web application. In those days Google App Engine supported just two languages: Java and Python, so my choices were a bit limited.

Although Python is a great language, it has strong performance issues, so I decided to rewrite it using something else. As I'd always been interested in functional programming, I started with Clojure, a modern Lisp dialect. I'm used to coding in Lisp being a student, although I'd never been serious about it. It became a challenge to deal with Clojure, because it really breaks your mind and spreads your horizons. I spent two months reading "Clojure for the True and Brave" and then about three months creating the first working prototype.

To make something good, you don't need someone's opinion. Just do what you really want to do.


Today I'm aware that Clojure changed my life. After half a year with Clojure I've become a different programmer than I was before. I decided to switch my career to functional programming. It took some effort to find a Clojure job, but nowadays I'm happy to develop with Clojure(Script) not only for a hobby project, but for my daily work.

I've added more data sources since the initial release. In addition to Twitter, I've added Google+, Facebook, and Instagram. These three have more limitations than Twitter, unfortunately. For Twitter, I've added more filters and search options, for example to the ability exclude reposts, search direct messages, geo-spatial search, and so on.

Indie Hackers community member tvmaly asks: What's your process for deciding what new features to add to your service?

I don't have a strict pipeline for that. I put every idea that comes from email or my feedback service in a special file, and I roughly estimate how long it will take to complete them.

Since I run the project from within my primary job, the particular order depends on how busy I'm at the moment. When I'm not busy, I implement the most serious ones. I also try to alternate both technical improvements and business features to make the pipeline more interesting. So I don't have any strict rules here.

What strategies have you used to attract users and grow Queryfeed?

First, I sent an application link to my friends. I published an article on a famous Russian technical site called Habrahabr. I also created a Twitter and Facebook accounts for Queryfeed. When I post an update in the project's blog, it's published on both social networks automatically.

The pool of paid subscribers changes all the time. People subscribe, then cancel their order and disappear. It's very difficult to get their feedback sometimes. I'd like to ask them: Why did you cancel? What was wrong? Just tell me the reason and I'll fix that. And when I see somebody has canceled their subscription almost immediately, I return the money manually via PayPal transfer.

One time, a customer asked me to add some feature. It wasn't difficult, so I made it quickly. The guy was a reasonable man from a big company, and he ended up writing a post in their official blog about Queryfeed.

Sometimes, people ask me for something other than improving Queryfeed. For example, to help them with calling an HTTP API or other programming stuff. Since I've gained some experience in those areas, I always respond.

How does your business model work? What's the story behind your revenue?

My business model is quite simple: use Queryfeed for free whenever you want. Once you've got a response, it is cached for one hour. That means you'll get the same response during that hour even if new tweets appear on Twitter. If you want to get fresh data immediately, you can order a paid subscription via PayPal. This lowers the cache time to 15 seconds and adds more data to the result.

Currently, there's only one type of subscription: $4.99 per month. It works via PayPal so people trust it. Users can cancel their subscription either via the Queryfeed dashboard or through PayPal's website. There's also a button for Russian users, since they're special in the eyes of PayPal. To receive money from them, I have to provide a subscription in Russian rubles.

When somebody cancels their subscription, I get a notification from PayPal which includes the customer's email. I ask them to send me their feedback regarding the service. Some people reply, which helps me prevent losing clients.

I have had some trouble with PayPal, both technical and organizational. For example, they may send payment notifications in the wrong order. Not "init, payment, success", but "payment, success, init". That's terrible, because you have to write extra code to handle that case. Also, one day they just turned off notifications. People paid, but the server didn't get any requests from PayPal. When I found that, I had to process a long list of transactions and manually send personal emails with my apologies.

I've been thinking about using Stripe rather than PayPal, but they don't work with Russian clients. They require you to register a firm somewhere in Europe or the USA, but I'm not ready to invest my time and money in that.

At the moment, I have about 35 paid subscribers who bring me $150 per month. That's not as much as you might expect, but I have never intended for Queryfeed to become popular and widespread.

I spend $80 per month on hosting, which is pretty high. I need a server with a powerful CPU to handle all the requests. There might be a case when two small servers may handle more requests than a big one, but at the moment I don't have time for such experiments.

The biggest lesson I've learned is that once you've got a product, add a PayPal/Stripe button as soon as possible. Sell your product immediately. Don't spend weeks tuning your OOP data model or optimizing SQL queries. Nobody is interested in that. Just sell the product.

What are your goals for the future, and how do you plan to accomplish them?

For the near future, I'm going to make Queryfeed just work without downtime.

I've also gotten a couple of good ideas through a feedback widget and emails from customers. In general, they ask me to add extra filters to get more precise results.

I need to fix the RSS structure to make it work with the IFTTT platform. Currently, Queryfeed breaks some requirements of the official RSS standard. That prevents using it with some other services. And of course, there are lots of hidden technical details to improve.

What are the biggest challenges you've faced?

I've faced lots of challenges with Queryfeed. Here are some of the most annoying ones:

  1. Initially, I used Google App Engine cloud platform. It allocates you a small amount of resources for free so you don't need to spend time on monitoring all the stuff. The first launch was quite simple. It costs nothing to support when you don't have active users. You know, a cloud platform is like a drug — the first dose is free and they really support your decisions. But once you've got some traffic, the billing report grows fast, and one day you can't pay them.

  2. Every social network has barriers to prevent abusing their API. The most serious problem was API rate limits. To solve it for Twitter, I had to register over 50 Twitter applications and declare a 50-element array of public and private key pairs. These days, it's not so simple. Each Twitter developer account can have no more than three applications. So I had to register fake accounts like queryfeed.foo1, queryfeed.bar1, etc. and store credentials in a secret file.

  3. I didn't expect people would use my application so much. So I've experienced serious performance troubles when the CPU reaches 100% and you see just a white screen. Often, I had to buy the next hosting plan paying from my pocket rather then fixing the code.

  4. When most of your consumers are programs, you'll definitely face problems. Surprisingly, machines don't sleep. I mean, usually a person visits their favorite sites in the mornings, for example. But if you set up a script, it would ping the remote server every 15 minutes no matter if there is an early morning or a late night. Once you've got lots of scripts, it becomes a challenge to serve all of them.

What were your biggest advantages? Was anything particularly helpful?

I couldn't say people supported me a lot. My family didn't know what I was doing, and the comments on the first post on Habrahabr were picky. That's normal, I think. To make something good, you don't need someone's opinion. Just do what you really want to do.

My best decision was to keep the project small. Even now, it consists of about 10 modules with 200-300 lines of code each. I don't use Docker, containers, virtualization, or dedicated servers for each logical domain (I mean, an application, a database, a cache server). I just compile a new version on my Mac and upload a jar file by SSH. And it works.

Nobody is interested in your success. They will try to interrupt you all the time… You've got to deal with that.


It would've been impossible to switch over to using Clojure for my project without having a strict schedule for myself. For a long time, I've spent one hour learning Clojure every day before my job. No more morning Facebook with coffee and cookies. No more funny pictures and links in Skype. It wasn't as simple as it sounds to keep that promise to myself.

The most important idea I've got from this challenge that is nobody is interested in your success. They will try to interrupt you all the time. Once you'd like to share you thoughts on Lisp, they'll start picking on you telling you old jokes about parentheses, Emacs, and broken hands. There could be a situation when you feel you are totally alone with your doubts and nobody can give an answer. That's normal. You've got to deal with that.

What's your advice for indie hackers who are just starting out?

In conclusion, I'd like to share some bits of advice that have helped me in my career:

  1. Get things done. I know, that sounds too abstract, and it's difficult. But it's worth it. Ignore all immediate desires to rewrite everything from scratch using a new modern framework. Your result is a boolean function with a binary output: it either works or not. Nobody is interested in the behind-the-scenes, how long you've been developing that gizmo, how many layers your neural network has, and so on.

  2. If you're a programmer, focus on getting the program to work first, no matter how ugly the code is under the hood. Write the simplest code you could ever imagine. Break patterns, SOLID, and all those modern practices. Just use plain functions and data structures like arrays and hash maps. You don't need to declare a User class to process a simple {"name": "Ivan"} JSON string.

  3. Don't believe anyone when they are talking about their success. They likely overestimate their results. The sums of money they are talking about might be two times greater than they really are. Same with their income, traffic, unique users, hits, etc. They want it to be true, but don't be fooled by yet another success story. Successful people just work.

  4. Read books about business and negotiations. Start with Carnegie's How to Win Friends & Influence People. Read Jim Camp's Start with No. I was also really impressed by The Goal by Eliyahu M. Goldratt.

  5. But read books sparingly. It might be a personal trait, but I need some time to think about the book I've just finished and retell it in mind. In between two books, just read blogs of professional people: writers, journalists, doctors, programmers, editors, etc... just people who do their craft better then anyone else.

  6. Never blame your family or parents when they want to share your time. Some people believe they can become a new Steve Jobs or Elon Musk if their families just leave them alone. That's nonsense. Lots of famous people were married and raised children but became successful somehow.

  7. To achieve something, even a simple thing, you have to work hard. There is no luck in the long term. You are not an exception.

Where can we go to learn more?

Please visit Queryfeed:

If you have any questions or ideas, I'll be glad to answer them in comments. Thank you for your time!

igrishaev , Creator of Queryfeed

Want to build your own business like Queryfeed?

You should join the Indie Hackers community! 🤗

We're a few thousand founders helping each other build profitable businesses and side projects. Come share what you're working on and get feedback from your peers.

Not ready to get started on your product yet? No problem. The community is a great place to meet people, learn, and get your feet wet. Feel free to just browse!

Courtland Allen , Indie Hackers founder

Loading comments...