This is going to be a small post about an excellent tool I discovered recently. I was refactoring a large RSpect suite and trying to speed up the execution time. I wanted a reliable benchmark tool to determine where the time is spent the most and which tests are taking most of the time. That’s when I came across test-prof.

Rather than me, the official documentation of test-prof is excellent in explaining all the APIs it supports. Here it is.

Out of all the goodies the tool has, one that has found its way to most of the spec suite was the let_it_be helper it provides. Its a simple helper that avoids the usecases where you used to use instance variables in a before call to setup non-changing test data.

before do
  @draft = create(:post)
  @published = create(:post, draft: false)


 let_it_be(:draft) { create(:post) }
 let_it_be(:published) { create(:post, draft: false) }

By this you can still with the goodies of proper let usage but at the same stop abusing instance variables. This and much more are documented here.

Couple of months back, I came across a launch post on Hacker news, it was a remote job board. There was nothing new and from the looks of it, just an aggregator from other job sites. Following that, there were some chatter on twitter around how “unoriginal” job board ideas are and no one should build it. These were coming from some of the “original innovators” in the indiehacking circle :).

Anyway, stemming from the tweet I jokingly remarked to my colleague that I’m going to build a remote job board next and registered It stands for “Yet Another Remote Job Board”.

Apart from the joking remark, this was something I’ve wanted to build for quite a while as the current “remote” focused job boards needs an improvement. When I refer to the job boards, I’m referring to the big 2. WeWorkRemotely and RemoteOK.

Both these job boards are no different than a traditional job boards with just a list of jobs and its description. The categories & tags are applicable to any jobs, not just remote. As such, I wanted YARJB to be a remote-focused job board.

What I mean by “remote-focused” is to categorize jobs on their “remote” attributes. Few of such,

Fully / Paritally Remote

Does the entire company / team works remote or only the position?

This is an important trait for a remote job. A company / team that is fully-remote is almost always better for remote than when few employees of a team work remotely. This could cause communication concentration and often leads to remote employees being left out.

Daily touchpoints

Does the company / team have daily sync up calls?

Be it a standup, product updates or even water cooler chat, synchronized touchpoints do improve co-ordination and leads to better understanding of the company and teammates.


Does the company organizes yearly / half-yearly offsites?

Apart from the regular touchpoints, offsites that enables the team to physically convene at a location plays a huge role in having the “team” sense and the belonging.

Pays locally / standard

Does the company pay according the local market rates of the employee or a standard benchmark?

Few companies pays the local market rate and few have a standardized benchmark that doesn’t deviate much from the high cost of living counterparts.

Apart from these, there are several others that I want to incorporate, like for example

  1. Remote Tools
  2. Team size
  3. Company size
  4. Timezone presence and more…

I would expand this list as it progresses. For now, I’m going to start with an aggregator and source these jobs from other existing sites. The categorization will be initially done my myself doning the detective hat.

If you think I have missed categories or any feedback please write to me at “mail (at)” or on my twitter avinoth_

Sorry if the title feels misleading (I didn’t intend to), this has nothing to with the number “2” in particular, just that I have launched 2 products on ProductHunt and the outcome was vastly different from those with no co-relation or causation implied.


First product posted on ProductHunt, it got all of 3 votes (all from my friends), dejected I left it alone and went ahead with life. 5 days later, I get a twitter notification that my post got more than 1000 votes. Seems PH posted my product back again that weekend and it picked steam. It ended up being #1 product of the day and I just have a theory on why they might have picked mine up and why at that time. But that might sound far-reaching and without backing of data, so I’ll leave that out of here as the world has more of it already.

ProductHunt: Website:


This one I was looking forward much as this was my first proper SaaS. And also, since I already had a highly voted product (got some followers from it), figured I’d get decent reception on ProductHunt. Ended up getting all of 6 votes. Greedy and hopeful as I am, I waited to see if PH would pull another card like they did with my first product. Nothing.

But… as a surprising turn of event the product got picked up by a tech blog, and from there another and with some big names following suite. It just snowballed from there and I ended up getting more signups from there than I could’ve anticipated from ProductHunt success. I still continue getting users from these referrers and they have been of huge help in SEO front.

ProductHunt: Website:

So my take is, it doesn’t matter whether the product has “successful” launch with 1000s of upvotes or left in oblivion on launch. As many have said before me, launch day is only the first day of your Product.

Put your head down, continue your grind and talk to your users. The growth maybe slow, but the foundation you build will be strong.

As mentioned in my previous post, here is the roadmap I have planned out for Finesse this year.

Broadly I want to focus on 4 different categories of features, each with its own merits.

Read more

For the past couple of months, I’ve been hard at work in completely revamping the user experience on Finesse.

This includes changing the whole frontend framework (bootstrap to semantic-ui), redesigning all the pages and completely rewriting all the front-end code involved.

Read more