Remote Tools is a community to discuss, learn and grow remote work. But it’s not the startup that kickstarted my entrepreneurial life. It began with Flexiple – a premium tech talent marketplace. As one does, we wanted to find that one breakthrough idea that brings us great leads for Flexiple. We came across how Hubspot,, and Openmargin used side projects (Website Grader, Unsplash, and BetaList respectively) to drive growth. This motivated us to think in a similar vein and to come up with a side project that would be relevant to our audience.

Once we defined our target audience – tech startups that are comfortable with remote working, preferably in the US or Europe – we started brainstorming ideas that would:

  • Be useful to our target audience
  • Use resources (tangible or even just our knowledge) that we already had
  • Require only a simple product to be built, without requiring much maintenance
  • Allow us to market Flexiple subtly

Since we had used and tested a bunch of tools that were great for remote working, we decided to build a curated and comprehensive repository of tools for remote teams, new entrepreneurs considering hiring freelancers and remote workers, or even freelancers in general. Thus was born, Remote Tools, with over 100 handpicked products across 24 categories useful to remote workers.

The origin story might not seem as detailed as you might like. However, my intention is not to focus entirely on the inception of Remote Tools as an idea, but instead to paint our journey to date. Just in case you would like to read more about the inception and our analysis, you could read my article on it.

How we built and marketed Remote Tools?

We kept the product super simple. It was built on WordPress and was entirely static – no user interaction. We decided that it didn’t make sense to invest in anything complex before receiving any traction on it. This meant that the focus was to create a clean website, not a fancy one, with the sell being the concept and quality of the information provided.

We prepared for the launch by joining relevant Slack and Facebook communities in advance, reaching out to publications, amongst other methods. But, honestly, the one source that really delivered for us was Product Hunt – we ended up becoming the second-most loved product of the day and received over 10,000 visits in the space of a few days. We landed a fair number of clients for Flexiple through the launch, and recouped multiple times our initial investment.

I can’t recommend Product Hunt enough to anyone. Following certain best practices allows you to receive a ton of traffic from the platform. We took the liberty to detail the process so that others can also benefit from it – it still requires discipline in execution. Don’t underestimate the potential of this channel.

Learnings from the launch and next steps

Apart from all the traffic, we got a lot of positive reviews through the launch. There were feature requests, but most importantly, we sensed a certain fervour with which people spoke about remote working. This made us realise that the game with Remote Tools shouldn’t be a short-term one – we could potentially build something really big here.

We decided that the concept could be a “Product Hunt for remote-first products” (I’ll share later why this wasn’t the smartest idea). So we planned to add some user-engagement features – upvotes, comments, addition of new products, etc.

The biggest miss in this entire launch, however, was to not request the visitors to share some contact information. This would have allowed us to already have a userbase to share our product updates with. Unfortunately, we had missed out on setting a great platform for our next launch.

So, we began the product development of our next version

Having decided that our next version would be a “Product Hunt for remote-first products”, we ideated the best way to build the product. As we already had access to some of the best developers through Flexiple, we decided it might make sense to work with one of them to build the product.

Due to concerns about the scalability of a product built on WordPress, we came to the conclusion that we should build it from scratch again and on a more scalable technology – we chose Ruby on Rails. In hindsight, each of these arguments weren’t very smart.

Mistakes made in product development

Just because you have access to developers or even if you are a developer yourself, it doesn’t mean that you should start coding from scratch. Once the use case of your product has been decided, you should:

  • Immediately search for ready-made products that can address your requirements. Maybe, not all your needs would be addressed by the product – however, it is still a quicker, cheaper and smarter way to get to market. Long after putting in all the time & effort into building from scratch, we foundĀ this WordPress theme – wasn’t a great feeling.


  • Use no-code tools to build your product. No-code platforms enable anyone to build complex products without writing a single line of code. You can be super-agile in building products… all without needing a developer to build it or make changes.

With a vague concept of how users might interact with the product, trying to build the “perfect” product is a bad idea.

Product built. Now what about engagement?

Nevertheless, we built a decent product and started to reach out to remote-first product makers to post on our platform. We were sure that a majority of product makers would be more than happy to add their product to another distribution channel. So, this did allow us to have a large number of products posted on our platform.

However, once posted, there wasn’t too much engagement on the platform – either by the product maker or any other users visiting the website. That’s when we dug in and added a lot more avenues of user engagement beyond comments and upvotes. This included:

  • Live chat
  • Social hooks
  • Pop-up forms
  • And other useful widgets (like Beamer)

I think building engagement on a platform purely though your product requires an entire session to itself. I am still learning as I continue to build the product, but we have documented most of them in our Indie Hackers article.

Is the vision achievable?

While these initiatives did help us see more engagement, our vision of getting similar engagement to Product Hunt (realigned to our much smaller scale, of course) wasn’t coming through. So we did what we should have done in the first place – checked how Product Hunt and similar products built their userbase.

This is when we realised that such platforms (PH, Indiehackers, etc.) built their communities by initially starting something simple and useful – newsletters, twitter updates, engaging stories, etc. So, that brought us to the list of initiatives that we are currently working on and that are working for us too.

The right way to grow (probably?)

Along with discovering the origin stories of similar communities, even as an undercurrent we felt that just providing remote-first products was a tiny part of the remote working movement. We needed to provide more. We felt that content needed to be the way ahead. And seeing that other communities also took the content-first approach gave us more conviction. That’s when we decided that Remote Tools needs to be a “community to learn, discuss and grow remote working”.

So, we started the following:

  • Newsletter: A very personal newsletter that analyses and discusses a concept, challenge, or a general aspect of remote working each week. It goes out as a personal note in a conversational tone, letting the readers note that it was handcrafted for them. We have been able to grow an audience of 2700 in less than 4 months. Our metrics are strong – an open rate of about ~45% and unsubscribe rate below 1%.
  • Podcasts: We began inviting leaders of top remote companies such as Gitlab, Invision, etc. onto our podcasts to discuss remote work. These content pieces allowed us to gain more knowledge around remote work, place ourselves in the larger narrative of this space, and provide value to our newsletter audience and website visitors.
  • Remote worker stories: Given the still-nascent nature of remote work, we recognised that remote workers (both current and aspiring) might want to know what others are thinking and doing. So, we started Remote Work Chronicles to give them an avenue to share their stories and read those of others.
  • Other content initiatives: We keep releasing strong content pieces like our Remote Work 2020 guide to emerge as the thought leader in this space.

We believe these initiatives are the necessary precursors for building a strong community. As in any entrepreneurial venture, we still might successfully reach our end goal, I believe this is the one viable way of achieving it.

What we learned

Although I prefer to share stories, I know others learn differently so here are the bulletpoints…

  1. Consider building side products to power the growth of your startup.
  2. While building the side product, Utilise your strengths and existing resources for it.
  3. Before starting out on any product, Search for off-the-shelf alternatives so you don’t build everything from scratch. Use no-code tools – whether you are a developer or not.
  4. Take Product Hunt seriously as an acquisition channel and prepare religiously for it.
  5. Prepare your product to capture users once you launch.
  6. User engagement needn’t be through complex features. Use individual services to add an element of dynamics to your website.
  7. While you can’t be researching forever, try to find the closest successful product to yours and understand & adapt their growth story to your context.
  8. Don’t be afraid to accept your mistakes and pivot to what you believe is the right course. Continuously analyse all the data points you have and take decisions accordingly. In the future, you will have more data points which could change your past decision – that doesn’t make your past decision wrong.

About Karthik Sridharan

After slogging for 3 years at J.P. Morgan, Karthik joined IIM Ahmedabad for an MBA and began exploring a passion for entrepreneurship, which led to Flexiple and Remote Tools.