Indiehacking: a review of my 3rd year

Each year I take this time of year to reflect on how I progressed towards my goal of being self-sufficient as a web developer:

This year is no different, even if it was a total mess.

Table of contents

How I Indiehack
Investing in tooling
Books I Read
Year in review
Financials
Learnings
How my fourth year is going

How I Indiehack

To save you reading through the previous year's summaries, here's how I indiehack.

I try to keep either a full-time job that doesn't expect me to work 18 hour days to meet tough deadlines, or I take contract/day-rate jobs where I can negotiate to work 4 days a week.

Before and after business hours, and occassionally on weekends, I work on side-projects.

I tend to work in 1-2 hour increments, partly because that's how long I can focus at a time, and partly because I prefer to chip away at a problem, rather than making one big push.

I started the year with the firm belief that running your own one-person SaaS was the only means of starting your own business as a developer. I now see that SaaS is just one type of fix, in a spectrum of fixes - from books/videos/workshops to consulting, to SaaS and other products.

Investing in tooling

I'm not a big fan of re-inventing the wheel when I build my side-projects, so in previous years I invested time in building my own personal framework to spin up SaaS-like solutions.

This time around, instead of investing time, I spent a few hundred dollars on licenses for Tailwind UI and Divjoy (referral link).

I still maintain a terraform config for spinning up the required infrastructure for my projects, but now I don't need to think about styling my side-projects, or fiddly integrations like Auth0 and Stripe.

I was able to productionise a web app for one of my projects this year within a couple of hours thanks to these investments.

Books I Read

Until this year, I rarely sat down to read books. Instead, I'd use my commute time to work to listen to audiobooks. As a result, when 2020 happened and I stopped commuting, I started having to make time to read, and as a result of that, I was much more impatient with boring or long-winded books.

Here are the ones that made the cut:

This is Marketing - Seth Godin
How I Built This - Guy Raz
How to Take Smart Notes - Sönke Ahrens
Originals - Adam Grant
Tribes - Seth Godin
Obviously Awesome - April Dunford
The Tipping Point - Malcolm Gladwell

Year in review

Mercenary for hire

I started the year completely burnt out from working for companies that claimed to have certain values, while exhibiting behaviour that ran counter to those values.

So I started looking for React gigs where I could jump in, either fix or build a React app, and jump out as the client needed.

Day-rate contracting

At the end of 2019 I complained across my network long enough that I managed to find myself working as a contractor for a scrappy startup building an entire IoT platform (from devices up to a frontend to display data). Thankfully they had hired a consulting company to handle the IoT device and data ingestion, so I only needed to worry about the web platform.

What started off as a couple of weeks to help the company get to demo day ended up being a few months helping build the company's entire tech stack.

As a result, overnight I unofficially became the:

Product Manager
Frontend Dev
Backend Dev
Data Engineer
SRE
DevOps

and it was surprisingly doable, with the right tech stack (Spoiler: I'm a huge fan of Choose Boring Technology).

Startup Tech Stack

I opted for the same tech stack I know and love for my side projects, and it worked quite well.

For managing tasks/documentation I used Jira and Confluence,
for the frontend I used React via create-react-app.
for the backend I used postgres with a node GraphQL server,
for Infrastructure as Code (IaC) I used terraform,
and for CI/CD I used CircleCI (though these days I'd probably look at using GitHub Actions).

On the data engineering side of things, we would regularly need to transform ad-hoc user-provided data into a format that our system could understand. Essentially, clients would already have IoT devices from competitors, and we would make it possible for them to join our platform via our data engineering efforts.

I was able to automate most of this using Python and AWS S3's event system, so we wouldn't need to wrangle the client's custom datasets more than once.

Side note: it blew my mind how incumbent companies can still charge $10k+ for systems built more than 20 years ago, that these days could be replaced by an ESP32, wifi/3g modem and a python script. Though being able to compete with these companies requires a large professional network and willingness to run high-touch sales that I don't have.

PerfBeacon on the side

While contracting four days a week, I would also work on PerfBeacon before and after work, as well as on Wednesdays. For those that don't know, PerfBeacon helps you keep your app/site fast by automating Google Lighthouse checks.

I managed to finish building the minimum viable product early this year, and started marketing and sales.

After launching PerfBeacon to the world, I built a quick CRM in Airtable, and started selling it to people in my network. I estimate I spent around 40 hours trying to sell PerfBeacon to my network directly, netting approximately zero in sales.

It didn't take long for me to realise that most of running a side business is marketing, rather than product building. Realising I was terrible at marketing, and didn't really know what I was doing lead me to pay for 30x500.

I still run PerfBeacon, it only takes a couple of hours a month on average to keep it running.

Funnily enough, while job hunting this year I ran into some resistance from startups "wanting me to be 100% focused, even outside of work hours on their project". In other words, I would have to drop my side-projects to be able to work for them. Often within minutes of telling me my "vast experience with React" made my profile interesting (I wouldn't have a vast experience in React without side-projects).

Total non-starter, so I kept looking.

Back into stable full-time work

Effectively doing any one of six jobs each day grew old surprisingly quickly, and by February I started to look for long-term contracts at more established companies.

By chance I decided to reach out to a recruiter from Atlassian that ran me through the interview process a year prior, and I managed to get another run through the interview process to be a frontend developer on the Growth team at Atlassian.

I ended up getting the job, and it's been fantastic.

Trade-offs, trade-offs everywhere

Working at a huge corporation like Atlassian has made me appreciate trade-offs much more than any small company ever did.

We regularly run through DACIs (basically a fancy RFC) when making technical decisions. Where before I'd run a technical decision past an architect/CTO, I'm now able to tap into our entire department's expertise to get more context, and see any gaps in what I'm trying to build.

Writing weekly

I started the year only writing whenever I got inspired (basically, after something made me angry enough to write about it). While cathartic, this didn't do much for people who read my blog.

Instead of focusing on things that annoyed me, in July I decided to focus on regularly helping people. I knew quite a bit about React from using it in production for several years (both on side-projects and at work), so it'd be a shame not to share the knowledge.

Since starting to blog more regularly, I went from an average of 20 readers on my blog per day, to about 140 readers per day on days when I don't post my articles anywhere, up to 2500 a day when I do share my articles.

Taking notes

Writing weekly has become easier as I started to treat my articles like "semi-permanent notes" to myself about certain topics in React.

I tend to take notes (whether in a notebook, on my phone, or on scrap pieces of paper) from wherever I see people discussing React (Twitter threads, reddit posts, etc) and eventually type them up into an article. Eventually, I revise the article as I find new information. A good example of this is Keeping up with React Libraries.

I learned this process after reading How to Take Smart Notes by Sönke Ahrens, which I'd highly recommend to aspiring writers out there.

Writing a book

After writing consistently for a few months, I started to notice the articles that would get significantly more traffic and links than others.

In the end, I decided to write a book to try help people more than a few blog posts ever could. It's called useEffect By Example, and I launched it in January 2021.

Financials

PerfBeacon is now break-even (in terms of running costs), averaging between $1-200 MRR.

Judging by pre-orders alone, useEffect By Example looks like it'll beat PerfBeacon in terms of revenue, even in the long term, and, even though PerfBeacon runs on a recurring subscription model.

I'm still very far from being able to employ myself, but at least now I have a repeatable process that works - writing consistently.

Learnings

SaaS is only one way of solving problems for your customers. Explore all possible means (books, videos, workshops, consulting, code snippets, plugins) of solving a problem before diving into building a SaaS. SaaS is often the most difficult, and time consuming way to run a business, and there are no prizes for playing on hard mode.

Pre-sales are an incredibly powerful tool to gauge buyer interest. Indiehackers can easily start a gumroad pre-sale to take valid credit card details, and only process the payment when they ship.

Write regularly. Similar to running/working out, the more you work out the muscle, the easier it becomes. There are unintentional benefits to this:

Writing documentation, emails, tickets, etc at work becomes easier
SEO: the more you write, the more long-tail keywords your articles will pick up - note that helping people is the goal here, not "winning" the top spot on Google
You grow an audience that wants to see what you're regularly creating
You get to practice shipping in a way you wouldn't get if you only focused on building product.
- Building OnlineOrNot and PerfBeacon, I got to experience launch anxiety perhaps once every six months, while with my writing on MaxRozen.com I experience it weekly.
- This in turn has taught me lessons on editing, marketing, running a newsletter, engaging with the community, and more that I probably don't even realise yet.

How my fourth year is going

In case you're wondering how my fourth year of indiehacking is going, check out my post on building OnlineOrNot.