Recently, I have built and launched a startup called RemoteBase and generated a first revenue. In this article, I would like to share what I learned from the experience.

Three months ago, I failed to launch my startup and wrote an article called What I Learned from an Unsuccessful Launch. Identifying and writing down the lessons helped me internalize what I did right, and what I could have done better.

With those lessons in mind, I went on to build RemoteBase. In less than three months, about 30,000 people have used the product, and there is a paying user. Based on this fact, I would like to self-righteously claim that the launch was successful this time.

For other makers and the future self, I decided to document some of my learnings. But first, let us have a look at what has led me here in the past six months.

How I Got Here

Six months ago, I spent two months building a code review software called Vym as a side project. You can see my excitement for that project in the post, I Am Making Vym.

But that excitement was short-lived. A month after launch, I completely lost my motivation to continue because no one was using the product.

After talking to my advisor Jack, I decided to move on to a different project, and started building RemoteBase. I wrote about my motivation in I Am Making RemoteBase. In short, RemoteBase is a website for discovering remote companies and jobs.

What RemoteBase looks like at the moment

I spent 10 days building and launching RemoteBase. Luckily this time, some people actually used the product when I launched, and I am still working on it three months later.


Here is what I have learned from my experience of building and launching RemoteBase so far.

No Need to Create Something Completely New

First thing I learned is that we need not create something completely new in order to generate wealth for everyone. A valuable product does not emerge out of the blue. It often borrows from others and uniquely positions itself by doing something different.

I borrowed a lot from NomadList to build RemoteBase. NomadList is a product that helps you find the best places to live around the world. RemoteBase is similar to NomadList in terms of looks and features.

NomadList was an inspiration for RemoteBase

The core functionalities of both sites are similar. NomadList gives you a list of cities and allows you to filter it. RemoteBase does a similar job with remote companies and jobs. Below is one of the first versions of RemoteBase I shipped:

The initial version of RemoteBase

I did not try to invent a groundbreaking feature or user interface with RemoteBase. Yet the product adds values to the world in its own unique way. It seems to me that being new is not a necessary condition for being valuable.

Some might be irritated by this divorce of two notions: the novel and the valuable. If we need not create something new to add value to the world, what is the use of our creativity? Should we forgo our creative urges and blindly follow the others? I think such questions arise due to the confusion between the concept of ‘new’ and ‘different’.

A product doesn’t have to be new; it just has to be different. A different product is idiosyncratic. It speaks to the world in a way that other products do not. You can make it look similar to other products, but it still speaks its own language. We should channel our creative energy into finding this unique language for the product, rather than trying to invent a complete game changer.

As makers, we all stand a chance of filling the world with our own voices. I think that it is a crime against our meaning on this earth to stifle what we have to say by putting others’ voices ahead of our own. To prevent the murder of our own voices and meaning, we are obliged to make a different product.

All in all, it seems to me that there is a line between copying and borrowing. Rather than engaging in a vain attempt to invent something that has never been seen before, we might be better off as makers by not being afraid of borrowing what has already been done.

You Will Throw Away Most of Your Code Anyway

One of the lessons I have learned from the previous, unsuccessful launch was to avoid perfectionism. The background for that lesson was that I ended up throwing away most of my code at the end. Such observation still held true this time.

We must not invest our limited time in trying to write a perfect code for our product. First of all, a code is never perfect, but only ever good enough. And you will eventually and inevitably throw away your ‘perfect’ code in the future.

Although RemoteBase currently looks and functions similarly to how it did in the early stage, it is a very different app under the hood. Over the past three months of iteration, its codebase transformed very rapidly.

In summary, there have been three main stages:

  1. The initial version was built with Meteor, a full stack JavaScript framework.
  2. I realized that while Meteor was good for prototyping , it came with all kinds of unnecessary stuff that only slowed me down. So I wrote a backend using Node.js for API and server side rendering (I wrote about my journey here).
  3. Now that I wasn’t using Meteor, I didn’t even need to stick with Node.js and MongoDB. So I recently invested a week to rewrite the API server in Golang and started using Postgres.

The current codebase has some vestiges of the initial version in some front-end components, but mostly it might as well be brand-new. You can have a look at the code for the original version in this repo. I no longer run most of those code.

In The Mythical Man-Month, Fred Brookes writes that “in most [software] projects, the first system is barely usable … Hence, plan to throw one away; you will, anyhow.” My first iteration was barely usable and broke at 200 concurrent users. I threw it away.

Some might argue that investing time to write a solid code is worthwhile because doing so would save time in the future and spare us from headaches. Yet such an investment, in my view, is unfounded because many times we do not even know if our ideas are valuable.

It may be that I am a lousy programmer, but I cannot justify investing an inordinate amount of time to making my code more pleasant, before I can prove to myself that my product can indeed add value to this world.

People Don’t Care About Your Product

Most people simply do not care about your product. I mean that they neither love nor hate your idea. Love and hate are strong emotions, and it is quite hard to get people get so emotionally invested to feel those emotions.

At times, the indifferent attitudes of people can be discouraging, but we need not interpret them as a sign that people dislike your product.

Your emails will be ignored, and your Tweets will be lost in the feed. Sometimes people will straight-up tell you that they are not interested in your product. But all these is because people do not care, not because they have strong opinions about your product.

After launching Remotebase, I spent countless hours cold-emailing scores of companies to persuade them to sign up for RemoteBase. Most emails went unanswered. Sometimes, I had to email companies four or five times just to hear them say that they are not interested.

But strange things happened over time. Many companies that never replied have signed up voluntarily. And the very companies that had told me that they were not interested also ended up becoming a user. After all, the users were not uninterested; they simply did not have reasons to care.

I do not expect most of my users to love or hate RemoteBase. Some outliers will have such feelings, and I will be extremely flattered that they care enough. But I came to terms with the fact that most users will be rightfully indifferent.

Given the apathy of most users, what must we do as makers? I think our job is simple. We need to keep on building without being discouraged by a seeming lack of interests, so that more people can either love or hate our products at the end of the day.

Some Will Get Mad When You Try to Monetize

Although it is hard to get people to have a strong emotion about your product, there is one surefire way to get some people to feel a semblance of hatred. Interestingly, all you have to do is to try to monetize your product.

Here are what some said on the day that I launched:

I appreciate your work but I think it’s shitty you are trying to build a subscriber list. For what? I get the good intentions but it irks me that you’re profiting off this “open-source” remote list.

Even though I was not even charging for the product, a person was offended because I was building a subscriber list. Perhaps what people are against is not the act of monetization, but an act of building traction.

You want this project to be your goldmine. People in this thread already provided companies you can use to compile your list and what do they get? The paltry traction you have gotten has been because of so called “charity”.

Also it was odd that criticisms were directed to me as a person, not to the product. Putting the pieces together, I have a hunch that these critics get jealous when a maker successfully builds traction.

The fact that someone is willing to pay money for a product is a legit proof of traction, and the critics cannot stand to watch the possibility of such a scenario unfolding.

You will get haters when you try to monetize your product, or even when you do innocuous traction building activities such as building a subscriber list.

When, not if, you face such critics, remind them that you are creating wealth for everyone and there is nothing wrong about doing so. You are adding values to the world, and they are just mad that you can.

Stop Building Your Car and Start Driving It

The importance of iterating a product has been preached repeatedly for startups. Yet, I see that there is something more important than iteration: you need to invest time and effort to get your product to be used.

I presented this topic at Product Hunt Sydney recently

Ever since I launched, most of my energy has gone into iterating the product. My attention was focused heavily on what feature to build next. I always assumed that iterating was the only sensible thing to do.

Through the popular startup literatures, my mind was conditioned to put iteration ahead of everything else. Iteration was all I ever thought about, and all I ever did. I was convinced that my obsession was warranted in the name of “moving fast and breaking things.”

For instance, when some companies started posting jobs using the third party form on RemoteBase, I immediately started building a fully-fledged job posting system on RemoteBase.

When I told my mentor Jack about my plan to make a built-in form for job posting, he told me that doing so might be unnecessary. He said:

You spent all this time trying to build the car. Now it is time to relax and take it for a ride. Don’t keep adding parts. It will not make you go anywhere.

Jack and me planning a new sprint

Jack is a self-proclaimed car person, so he had to use a corny car analogy. Yet I have to admit that the analogy is kind of cool, and greatly represents the essence of early stage product building. Building a product is a lot like making a car for yourself. If you keep building it, you will not go anywhere.

We, the makers, sometimes forget to take our car out for a ride. Instead we keep adding parts, and keep upgrading the parts we have already added. Perhaps we are either too forgetful or afraid; either way, we can never reach our destinations.

The pitfall of building the car without driving is real especially for developers. We keep seeing stuffs on Hacker News that we just have to integrate into our applications. That reeking piece of code bothers us until we refactor it. We want to write just one more test to make sure a feature is not broken.

Yet, a product needs to be used, just as a car needs to be driven. Otherwise, both the product and the car are practically useless.


It took me two years of non-stop hacking after finishing college to make a first revenue from something I created from scratch. Never having held a real full-time job as most of my peers do, I have felt lost time after time.

Whenever I felt unsure, I always dreamed of turning the first revenue, and pictured how happy I would be when I reach that milestone. But to be honest, I did not really feel anything when I made the first sale through RemoteBase. And I think I know why.

A Muay Thai fighter does not get elated when she lands a powerful middle kick to the ribs. A person at a gym does not get ecstatic when he deadlifts. Their training must have rendered their body and mind numb to their current achievements, with hands covered in callouses, and calf muscles desensitized.

I think I did not get excited over my first sale because it was not a windfall. Rather, it was a product of days and nights of learning to code and building countless things that have never even made their ways to the spotlight.

I am not saying that my efforts qualified me to deserve this successful launch. An effort does not justify rewards because everyone works hard. Rather, I feel that every hour I spent coding and selling made me a little bit stronger and number, in much the same way that weight training does.

There are still more lessons I want to share, but perhaps the most important one I can tell you is that everything we see is made possible by unseen efforts and processes that lead to it. The efforts almost always go unnoticed. Being a maker is a lonely like that.

Recently on Hacker News, there was a cool site called Indie Hackers, a listing of successful products made by hackers. I think that there is is one untold story shared by all the products on that list, and even the ones not on it: someone must have spent lonely hours writing the code and selling the product.

It took me two years to finally launch something that has even a modicum of potential for a success. I am not sure how it will unfold, but I built it, and I believe you can, too.

Edit Feb/10/2017

Here is my recent pitch of RemoteBase followed by a panelist discussion.