So Who Uses a Superhero API anyway?

A story about the Superhero API and the people who are using it

Hey guys! This is a story about the history of the superhero API, on which I've tweeted here and here. So I thought this would be a good checkpoint to understand the progress I made on it so far, and also create a document on how people are using it so far.

How it Started

Wayyy back in 2018-2019, I used to write technical articles for various publications. This was before I realised I could write for myself and grow my personal audience. An idea that I had pitched was writing an article on building an app for the web (using React), and also for the voice assistants (Alexa and Google).

I was looking for any pre-existing APIs I could use, but couldn't find any good ones. So, with no particular tech-stack in mind, I decided of building something around superheroes, since it has a really cool emoji in Apple (which is the current logo for the API).

To get started with it, I scraped a few superhero wikis and tried to fetch the common data points within them. Then, I dumped the data file into a Node app and queried the file on each request, while still retaining good performance. So, Vercel was a good candidate for this one-off application.

After the API was set up (which was the easy part), I managed to create apps for the platforms in mind, and my first article went live on freeCodeCamp. The voice apps do okayish, and the article must also have done reasonably well, because it became easier for me to write there and in other publications after this article.

So in a way, the API was built to serve me and I was the first user of my API.

A few months later (second-half of 2019), me and a friend were looking to apply to YC with just an idea. The idea was to build a platform for serving ML models, and we would seed the platform with an initial set of models. While doing the market research, I found rapidapi, and to test it out, decided to put the Superhero API up on it. The rapidapi experience was really great back then, and I eventually forgot about it. And no, we didn't get into YC ๐Ÿ˜‚ (Although we were told we were in the top 10% of applicants that year, it sounds more like a psychological play to make us reapply.)

For over an year, there wasn't much activity on the API, a few people were using it here and there, and I tried to experiment with monetisation for high-volume users. I landed somewhere around 1-2 USD MRR, which I didn't touch further for over an year. Mainly because I forgot this API existed.

Later on, in 2020, I decided to take a deeper dive into indie-making and decided to revive an old website update tracking Telegram bot of mine as an API. Although the API still has 0 users, I managed to get the superhero API into my focus again. This time I saw I had emails on feature-requests by users. By implementing them and moving to a Freemium model for the new features, I managed to optimise monetisation.

How it's going

After my optimisations back in December, I managed to hit 5 USD MRR with a completed user request. Later on, through organic growth, I hit about 23 USD in Jan, and recently 46 USD in February (which, you may remember, is near VPS profitability for me). Although, whether I can maintain this growth, or even the current MRR, is a different matter altogether. Broadly, people are using the API for:

1. Portfolio Projects

The benefits of having a pre-made API are many, you can focus on just delivering value via a frontend interface while the API developer handles the heavy-lifting of data gathering and manipulation. Projects like my own article and apps, where I used the API to show my React skills when I was just starting out, can take benefit of this approach.

Another user used my API to demonstrate their React and UI skills in a search tool, for applying to jobs -

2. Data Exploration Projects

It's useful to use a pre-existing API in a data exploration project. This is because all the data is already collected for you, you just need to access it in the right manner and make graphs and other visual things from it.

One of these projects is superhero ETL on GitHub, which "Combines the Best 50 Superhero Movies dataset with The Superhero dataset for the analysis and data visualization" -

Another user wanted the data directly to build a data visualisation of superhero power-levels which you can find here.

What the future holds

From here, with the Superhero API, I'm mainly focusing on maintaining the growth, or at least current MRR level, while making changes to the API according to user requests. For eg, adding regex-based search for a user who wanted multiple results for a query.

Other than that, I will be focusing on building other similar products with a focus on distribution and a clearly defined demographic. One of those is, which has a clear niche among Wealth Managers and Portfolio Managers in India.

So, if you want to follow me on my journey through these things, why not give me a follow on Twitter :).

Listening as an Exercise in Therapy

How to Listen to people and Make Friends

Photo by Franco Antonio Giovanella on Unsplash

Over the previous week, I have been trying to be retrospective, and one of the questions I asked was, "What have my best interactions with other people been? And, what was a common theme between them?". The common thread I found was that the best interactions have been when I and/or the other person is speaking their mind freely, and there exists something like a two-way bridge into each other's thoughts. The best way I've found to do this is by just listening.

Listening is one of the most fundamental and important tools of conversing. A good listener generally frees the other speaker to freely put their thoughts into words, and is able to react appropriately and timely, making the conversation move forward smoothly.

In all of the positive experiences I've had, they've always been when either I was listening as intently as the other person was speaking, or when I was listened to as intently as I spoke on a topic. On the other hand, the worst experiences I've had with people have been when either they keep interrupting when I've actually started talking about something with interest, or if they start talking and I accidentally interrupt them (although I try to bring back the flow by nudging them to restart now).

Coming to the title of the essay, I'm not sure whether listening is actually 'therapeutic' in the psychological sense of the word, but it does feel so. The listener isn't pressurized to add his inputs or think over complicated matters, they just have to listen to the story being told by the speaker and nudge them forward in the story. This in itself can be quite a meditative exercise, because one can relax, while still having a good chat. This is especially meditative for someone like myself who would rather talk with someone rather than watch a show or play a videogame to relax.

So, next time you're tensed, or have had a hard time completing some task, why not call up an old friend or colleague, or just hang out with your family, and listen โ˜•.

Consistency as a moat

How to be consistent and how it helps

I have a theory, the most sure-fire way to be good at something is to be consistent at it. And the more you are consistent with something the larger gap that you create between you and your competitors. Everyone who you know is good at something(X) as probably been doing X, or a version of X for more than a while now.

But, you may ask, how to be consistent when the end goal is large or the task itself is large? The solution is to break down your goal into clearly defined & atomic tasks, and repeating an even more reduced version of that task for everyday, till you make progress on your goal. Mike Critter explains it on his blog here, "Tiny habits. No, like TINY tiny."

And, which set of tasks from these should you be practicing at a time? The ones you're bad (relatively worse) at. Taking this from the essay on deliberate practise, the best way to optimise consistency is to prioritize the things which you're worse at, or where you can have improvement.

Breaking this down for myself, let's take the example of the act of writing itself. I started writing by publishing larger articles to publications. These used to be code-heavy articles and so used to take 1-2 months to write, edit and publish. However, I figured out rather than writing for someone else I wanted to write to grow my own audience.

The first problem was that writing articles weekly was difficult for me. So, I initially started with writing an article every 2 weeks, I could pick up ideas throughout the week, experiment with them a bit and then write at the end of 2 weeks.

However, for a newsletter (which is what I'm aiming at growing), a weekly model makes more sense to keep your readers engaged, and also keep your writing muscles trained. My problem with writing weekly was that I couldn't find the words to think about at the end of the week, when you are generally in a relaxed mood and might only be in the mood of chilling. (There are benefits of not ending your week with "nothing", as explained by patio11 here.)

So, to break this habit down, I currently write only 200 words everyday. This is a tiny enough habit that by the time I'm done with 200 words, I already have the next 200 words thought of, and they just flow onto the page.

I also automatically stopped procrastinating when I tried to achieve only the bare minimum everyday. (The other way to stop procrastinating is turning off the internet, which no-one tells you about. - @hipreetam93)

And so, that's how I'm applying consistency for writing.

How is it a moat? Just look at everyone you admire, or look at the people who're good in a field, and research their history :)

Anyways, go out there, make mistakes of ambitions not of sloth, and finish your damn business EVERY SINGLE DAY.

Building React Applications using Deno: The Definite Guide - I

Getting started with AlephJS

Hey guys, this is the first part of a larger blog-post which Iโ€™ll be writing and publishing in various publications. Let me know your thoughts on this so I can improve it before compiling the final article. Thanks :)

For those just started with Deno, and those who work in the frontend, you might be having the thought, "Can I build something as complex as a NextJS or Create-React-App (CRA) application using Deno?"

I was thinking the same as I wanted to try Deno because of its better shareability resulting from the ability of running an application directly from a URL (The Deno compiler supports running JS/TS files from a URL and it also supports imports from a URL, resulting in extreme portability.)

I looked if any existing solutions, articles were there online, but only found this article, which built an SSR'ed React application using some complex techniques, nothing simple like getting started with NextJS or CRA.

So, through my searches online, I ended up at AlephJS, which has one of the coolest landing page animations ever.

Aleph is a Zero-Config, Typescript driven React framework, just like NextJS, the only drawback being that Aleph is still very much in Alpha.

So to get a true Next-like React experience inside of Deno, let's get started with AlephJS. It has much of the same conventions, such as:

  • /pages directory for creating URL routes

  • Direct .js, .jsx, .ts, .tsx support in pages

  • /public directory for serving static assets like video, audio, or image files

  • /pages/api folder for serving Javascript or Typescript files as serverless APIS.

Full stack; the most misunderstood role of all time

What it means to be a full-stack dev and how an organization can better use them

The most misunderstood role of all time is that of the fullstack developer. An inexperienced manager may try to use the abilities of such a developer to build out complete features, and a inexperienced, or misunderstood full stack developer might try to take on the task completely and all alone.

Most of the times, this results into disappointment and breaking expectations. One developer cannot hold the complete structural context of an application mentally. This results in loads of bugs; and always, with few exceptions, unseen bugs in the frontend. UI being such a fickle beast, a dedicated developer is needed to test, try to break, and fix the frontend.

However, where full stack devs actually shine is in building something in tandem with another dev. In the case of 2 developers, it's more than likely that each dev individually can hold the context for their respective parts of the application. 2 devs are also faster than one (however, how much this productivity actually scales is logarithmic, and further devs can mess up this delicate dynamic).

To make this work though, each dev should themselves be capable of supporting the other dev. This is not only in recognizing bugs, but in going into the depth of each bug and understanding why they happened, so that they save each other's time in debugging. This makes the team run smoother, and helps them take advantage of each other's strengths.

Anyways, these were my top-level thoughts on the topic. Let me know what you guys think about this :)

As always, follow me on Twitter for the writing dev experience.

Loading more postsโ€ฆ