Remoted

I shared my launch day story, including the incredible Reddit Brasil support here: https://www.indiehackers.com/andrerpena/post/a4ba398c26

The whole Remoted story and motivation is here: ❤️

https://medium.com/@andrerpena/releasing-an-indie-hacker-product-my-personal-journey-through-making-remoted-io-25b39ab9fe56

• Hosting: DigitalOcean. This one was hard, because I had zero previous experience with VPS management. I thought about releasing with Heroku, but because I plan to release multiple projects, it would be too expensive to go that way. It took me around 15 hours to learn and to to set up DigitalOcean, including Nginx and TLS. Now, to deploy a new website, it will be super easy.
• Database: Postgres. This one was also not obvious. For the majority of MVP projects, all you need is SqLite. A good reason to go Postgres is when you anticipate the need for full-text or spacial/geolocation search. Also, another question was whether to go managed or unmanaged. Again, because I needed to be able to deploy multiple projects, going managed would be too expensive. The feedback I received from a lot of indie hackers is that managing Postgres yourself is not as hard as it sounds. I'm having a good experience so far.
• App server: Node.js with TypeScript. Node is amazing for the ecosystem alone. You can basically find anything you need on NPM. For example: Sitemap and RSS feeds.
• Process management: PM2. This is only relevant for Node. Node runs only 1 thread per process. This causes the problem that you need a mini-load-balancer if you're using multiple processes. PM2 does that, PM2 also does a very good job organizing your logs/errors.
• Web server: Nginx. Node developers often don't understand why you would Need Nginx if you can use Express for everything. Three reasons I use it for: 1) TLS/SSL certificates from LetsEncrypt, including auto-renewing, was a breeze due awesome Certbot integration. 2) Node output cache and static resources cache is much better than anything you can do with Express. 3) Rate limit.
• Crawlers: Puppeteer: I believe no language can beat JavaScript/TypeScript for making bots, for the sole reason that you can execute your code inside the context of the browser. What I mean by that is: I can pass a function to Puppeteer, that I expect will run inside the page that I'm crawling. this is super useful for collecting information. If you make a crawler in Python, for example, even with Chromium is being used under the hoods, you would have to switch to JavaScript to control the browser, internally. With JavaScript/TypeScript, it's the same language, the code is more straight-forward.
• UI: React with Next.js + Apollo. Next.js is basically a runtime that allows you to use React with SSR out of the box. It's fantastic. Apollo made it super easy to set up my API.
• API: GraphQL. Not trying to predict anything, but there is a chance GraphQL will become the de facto standard for REST APIs because it is statically typed, self-documented and it enforces consistency.
• CI/CD: Codeship. One question I had in mind when I chose to run a VPS with DigitalOcean is how would I manage CI/CD, that comes out of the box with Heroku. The answer was Codeship. Basically, they will test your code and, if the code passes, they will deploy. They support deploying to all major cloud providers, but for a VPS, you just upload an SSH certificate and let them connect to your VPS, after a push and successful tests, and git pull.
• DNS and CDN: Cloudflare. Everybody uses Cloudflare. Most common use cases, not in a particular order: 1) Redirect www to non-wwww, 2) Basic DDoS protection. 3) Caching 4) TLS. Specifically for Remoted, I have the CloudFlare issued TLS certificate between the edge and my VPS, and a LetsEncrypt TLS on the

One of the problems I'm trying to solve to set Remoted apart from other aggregators is to provide better search options. When you are looking for jobs, you need to exclude the ones that are not compatible with your country or timezone.

I tried to detect, the best I could, if the job requires the candidate to be on a particular place. This is extremely challenging. There are 3 dimensions for determining restrictions: 1) It may be required or just preferred. 2) It can be based on timezone. 3) It can be based on the country the candidate resides/has permission to work.

For now, I have to look at the job post and try to extract keywords that might suggest these restrictions. I then attach a "location tag" to the post. I also added pre-defined filters based on the most common "location tags" like US, North America and Europe.

This is not a perfect solution and now I'm working on a much better search approach. I plan to release it in 1 month or so.

It was, first of all, a great learning experience. The only way to truly learn stuff is by doing and I did, indeed, learn a lot.

Apart from technologies that I learned, like GraphQL, Next.js and VPS maintenance and CI/CD, I learned how productive you can be when you're working alone and you don't have to align stuff with everybody. On the dark side of "working alone", though, one particular thing that stroke me was how people thought my product was unintuitive, even though I was building for developers, like myself ,to solve a problem that I, myself, had for years. My take away was: Yes, if you have years of experience, building alone is fast, really fast. But make sure you have constant user feedback even if you're solving a problem you consider yourself an expert.

No matter how familiar you are with the problems you're solving. You need a fair amount of feedback to get it right.