Founder Interviews: Erik Andersson of Feeder

After starting Feeder as a fun side project, Erik and his team eventually decided to go full-time on Feeder, and have since grown it to $10,000 MRR.

Davis Baer: What’s your background, and what are you working on?

My name is Erik and I’m the co-founder of Feeder. I’m a programmer and have been programming for almost 15 years now. I’ve previously been employed at startups big and small, but starting something of my own has always been my passion.

Feeder is a way to follow content that is important to you. It all started as an RSS reader extension for Chrome, but now we have extended our offering to be a cloud service with apps for all major browsers, mobile, and web. Our internal mantra is: “If it is online you can follow it with Feeder.“ Our users consist both of individuals and businesses from all different industries. It’s used for a range of different things. All from following blogs, getting notified of job postings, to the latest supreme court rulings.

Screenshot from our web reader

The team consists of me, Johan, my twin-brother and Mattias. I’m the programmer, Johan designer and Mattias is in charge of selling and being the business savvy person on the team.

Right now we’re close to $10,000 MRR (Monthly Recurring Revenue). Our MRR is up 121% since the same time last year. When we were featured on Indiehackers two years ago we were at $2,800 MRR, so it’s really cool to see the growth.

What motivated you to get started with your company?

Feeder started as a hobby project in 2010. I wanted to be able cut down on procrastination by getting notified when blogs I followed had updates, instead of opening a new tab ever so often. So we built a Chrome extension to follow RSS feeds. We let our own usage guide what we built, but users would find us and ask for improvements too. As a hobby project it kept gaining users without us needing to push for it.

At the end of, 2016, we had a discussion about the future. If Feeder could grow so much as a side project, what were the possibilities if we went full time? That question led us to take the plunge. We incorporated with about 6 months of runway in the bank (with one person at a ~33,000 USD salary). As the programmer it made sense for me to be the first to go full time. The others still kept their full time jobs. In March 2018 Johan was able to joined full time. Now we are at a point where can start thinking about the next person.

What went into building the initial product?

The initial version was built just using plain HTML, CSS and Javascript inside a Chrome extension. It was 100% local so there was no cloud backup or syncing to multiple computers. It meant fast iterations, but we hit a wall with what you can do just locally. To continue building new features we had to build a proper backend. In 2012, we did a “2.0 full rewrite” and it took about 3 months of full time work.

Around that that time we had just graduated high school and worked as consultants for various startups in Sweden. While doing this, we saved money to be able to take time off and focus on a single product. For us there was never any heart in being consultants, no real love for the products. It almost felt imperative to work on our own products.

Our first office was a spare room in our parents’ house. They were kind enough to let us paint a wall with blackboard paint so we could sketch ideas and notes on the wall.

My experience at the time was that I had dabbled in some PHP/Rails and setting up Ubuntu VPS servers for personal hosting. I knew absolutely nothing of scaling databases to terabytes of data or load balancing 100s of requests per second.

Grafana dashboard of our crawling microservices

The first backend was actually written in Node.js. My idea was to share the code between the local installs and the cloud installs. The same queries were run on a local-install WebSQL database as our on backend MySQL database. This quickly became a problem. Local storage is a lot more forgiving when it comes to performance. You’re only dealing with 1 user’s data, not needing to share resources with thousands of others.

Today we have a stack split into a couple of microservices connected via a couple of MySQL databases and Redis databases. Our web app servers run Ruby on Rails. Feed crawling and job workers are in Golang. We use TypeScript for client code (with Ember.js on our settings page and React for extensions/web reader).

It sounds messy but I’m actually quite proud of our system. It’s by no means finished, and the tools and software continue to evolve as we do. Besides the 2.0 rewrite, we have never stopped everything to focus on a huge rewrite. In my experience major tech rewrites have always been mistakes. Going piece by piece instead is the best way to maintain development velocity.

How have you attracted users and grown your company?

We started by adding it to Chrome Web Store and hoping people find it. It took about a year to reach 10,000 weekly active installs, then two years later we hit 500,000. The biggest growth “boom” came at around 30,000 weekly active installs when we got lucky and got a prominent position inside Chrome via the now-defunct WebIntents. When that happened it took us less than 6 months to reach 500,000 users.

Active Weekly Installs means the number of Chrome browsers with Feeder installed that are opened in a week. Obviously this does not equate to actual usage metrics. To be able to measure usage we use a custom service backed by a BigQuery database with Metabase for building dashboards. For logged in users we average around 10,000 Daily Active Users.

Daily active users of logged in users (excludes new users)

Before 2016, it was just me and Johan trucking along, rarely coming out of our product-building-shells. Via another project we met Mattias, a banker with many years of enterprise sales experience. He showed us that we had a lot of improvements to do on the external side of Feeder. From being a couple of introvert twins we had finally found our extrovert match. And in 2016 he joined as co-founder.

Thanks to this we started actually talking to our users. Be it phone calls, Intercom chat or via email. It was insane to see how much knowledge we missed out by not properly reaching out to our users.

What’s your business model, and how have you grown your revenue?

We have three different subscription levels, one free and two paid. Feeder Basic is free. Feeder Pro is for prosumers at $5.99 per month and Feeder Business is $15/seat per month.

Feeder started as free product. Early on, we experimented with donations. At its peak we would make around $100/month on our tens of thousands of users. To get more stable income we launched Feeder Pro priced at $2 per month. Last year we realised that the $2 pricing option had become unsustainable and needed to be changed. We made the tough decision to increase the price to $5.99 per month. Existing users were given a ease-in period at 50% off for a period of time. So far our users have been very supportive. For us it’s a validation that we actually deliver value to our users.

Monthly Recurring Revenue during our price increase

Number of subscribers (customers) during our price increase

For payments we use Braintree. When we launched it was our only real choice for card payments. Stripe had not yet launched in Sweden and all others were dinosaurs. We really wanted PayPal support as well. Due to the cost of such services we didn’t use any third party subscription providers, like Recurly or Chargebee. That meant we had to integrate directly with both Braintree and PayPal ourselves. This was a mess! Before landing in a decent setup, we would spend 50% off our time in the payments and subscription code logic.

Just keeping track of subscriptions, payments, refunds, cancellations, payment settings, etc, for one provider is hard enough. Each added payment processor will linearly increase the code required. Luckily for us, Braintree was acquired by PayPal and were able to add PayPal support into their own SDK. If were we could go back in time I doubt we would do anything different though. The pricing of services like Recurly would make a $2/month price point impossible. I really checked around if that has changed, but it would be way too much work to revisit that.

What are your goals for the future?

We can see that most of our paying users use Feeder in their work. So now we are focusing on building specific tools for them. There is definitely a big need for companies to be able to follow important content to them. We have a product called Feeder Business that serves companies in all sizes and in many industries: life science, big pharma, journalists, news agencies and banks to name a few. It is in its infancy, but we see people are liking it a lot. We are working on recruiting more users to understand and act on their needs. The next step is marketing, and we are trying hard to find the right marketing channel. Standing out from the noise is hard, and we have to do that to be able to reach out to potential users.

We have managed to build our company without outside investments by being financially responsible. The cash is secondary, but we probably won’t say no to an investor if they can help speed up our growth with great connections and/or their experience.

An important tool to meet our goals will be recruiting. Expanded engineering and marketing capacity would help us accelerate. The bottleneck in our product development is our engineering capacity. With only one developer that does it all, implementing new features and ideas takes time. We want to act fast on feedback. To get those features out to potential users marketing will be very important.

One roadblock for the future will be going out of our comfort zone. We are a small team with little experience in managing people, and we will have to take that step carefully. We are reaching the point economically where the next step is expanding the team. It will be extremely important to get that right.

What are the biggest challenges you’ve faced and obstacles you’ve overcome? If you had to start over, what would you do differently?

We are always open to trying new things. With that comes quite many (in hindsight) poor decisions. However, it is from those decisions we learn the most, therefor they are nothing we would want to have undone.

With the curiosity of trying new things comes the desire to jump to everything new. I think in hindsight we should have been more retrospective with a lot of things we tried. To understand what worked and what didn’t. We are not the best at looking back and reflecting. Of course a lot of positive comes from looking for new opportunities, we wouldn’t have been where we are today without that.

The biggest obstacle we overcame was having the courage to quit our day jobs and taking our labour of love full-time. It is quite crazy to think that we only had a fourth of our revenue we have now. I think we did the transition in a good way, but I also see that we could have done it faster.

Have you found anything particularly helpful or advantageous?

One advantage that has been particularly helpful is that we have all the abilities to execute under one roof. Designing great products, turning them into something tangible with programming, and then being able to talk to and form relationships with customers. It’s a double edged sword because we’ve never really had to look outward for skills and competencies. As we’re approaching problems we can’t ourselves solve we haven’t honed the skill find people who can solve them for us.

In terms of product development we’ve always let the user guide what we build. It’s easy to get carried away with this though. You really never want to say “No, that’s impossible” to a user because it feels great to be able to help. Many times it can lead to a loss of focus and releasing of some less-used features. We’re getting a lot better at this, and learning when to realise when a customer is just not a match for our product.

What’s your advice for entrepreneurs who are just starting out?

You’ll learn most things as you go. Don’t spend all your time trying to prepare for eventualities that might never happen. Just jump out there, and when something breaks you just fix it.

This was our approach when scaling our servers. A service or server slows down or crashes causing downtime. When that happens we know that it was time to scale up that specific component. Users are very forgiving of small amounts of downtime. We never wasted time and money prematurely optimising something, and because of it we have been able to keep our hosting very lean and cost efficient.

Also, very important: Get ChartMogul! It’s SaaS metrics provider that integrates magically with most billing providers out there. It’s such a great service and company, and I can safely say we wouldn’t be anywhere near where we are today without their insights.

Where can we go to learn more?

You can find us over at https://feeder.co. Our blog is over at https://feeder.co/blog.rss (or just https://feeder.co/blog if you’re not using Feeder yet!) and of course @feederco on Twitter and on Facebook.

This interview is brought to you by OneUp, a tool to schedule and automatically repeat your posts on Facebook, Instagram, Twitter, Pinterest, LinkedIn, and Google My Business