Reflecting on 14 months of indie hacking - Building 7 projects and learning hard lessons

TL;DR: 14 months ago, I quit my job to build indie products. Built 7 projects, currently at ~$45 MRR total across all projects, 900+ active users. Most projects failed financially, but learned valuable lessons about building for broad audiences over niche tools.

A little over 14 months ago, I made the drastic decision to quit my full-time job of 6+ years as Engineering Manager at Mercari to go my own path and find my own success.

It wasn’t a rage-quit or a “burn it all down” moment. It was a calculated risk to see if I could build a life entirely on my own terms. I’d like to reflect a bit on the year, how it’s going and what I’ll be doing going forward.

Do I regret my decision?

No, but it’s hard. I already went into this with the mindset that the first 50 or so ideas will fail, and maybe if I’m lucky, just maybe, the 51st idea will make some money.

Even with this mindset, actually failing over and over again is hard. We need small successes to understand whether what we’re doing is the correct thing, and being starved of wins is mentally taxing.

What I worked on: 7-8 projects over 14 months

The point of indie hacking is to move quick, try out small ideas, see what works and then focus more time or move on. Over the 14 months I worked on roughly 7-8 projects.

Looking back, these projects fall into three distinct buckets, each teaching me a very different lesson.

Group 1: The Dev Tools Trap

I started where I was most comfortable: building tools for other developers. This turned out to be the hardest path. The market is saturated, the users are demanding, and competing with free venture-backed tools is a nightmare.

Microfn (microFunction) - Your toolbox for tiny composable functions

• What: Cloud service, function runner and editor for small (micro), composable JavaScript/TypeScript functions. Hook them up to CRON, Webhooks, Agents over MCP or other automation platforms. It double serves as a dev environment for AI agents, to allow agents to quickly deploy code and use that code as new tools right away.
• How it went: 1 active user (myself). Fully functional and stable, but financially a failure. My partner lost interest and exited the project midway through, leaving me alone with it. No marketing has been done.
• Status: Feature-complete maintenance mode. It will stay in organic-growth-maintenance mode until usage picks up, with max 1 new development per week.
• The Lesson: Building a dev service is hard; getting people to switch from their existing workflow (Vercel, AWS, etc.) is near impossible without a massive marketing budget. Ad keywords are always outbid by the bigger players (Cloudflare, Google, etc). The potential is there, but it needs it’s killer-feature moment.

MCPNest - Host your MCP servers in the cloud

• What: https://mcpnest.dev - Cloud service for running MCP servers with focus on simplicity. This was an experiment built at the peak of the MCP servers craze. It greatly simplifies re-using sets of servers, for example to have a specific set of servers + tools for a dev persona, one for a casual persona.
• How it went: 14 WAU, currently pays for itself. Financially a failure. Active dev time roughly 1 week.
• Status: Active, low maintenance. As long as it pays for itself it will continue. It’s very low maintenance and does what it claims to do very well.
• The Lesson: Even jumping on a “hot trend” (MCP) isn’t enough if the audience is too niche. The timing could should have been 1-2 months faster to really hit the peak of the MCP craze.

Mailwire - Smart Email Proxy

• What: Mailwire is a transparent email proxy for power users. This is not a new project and already alive for a couple years, although in maintenance mode. It sits in between the users email client and their email server, and adds power-user features like auto-stripping of sensitive information or rewriting email senders ([email protected]) to match the recipient address ([email protected]). Active development time was many many months a few years ago.
• How it went: 2 active users, a big failure.
• Status: Low-energy maintenance mode. As I’m a user myself and need all of this, it will continue, but stay in maintenance and low-energy mode.
• The Lesson: This app is just too niche. I built it for myself, and turns out, I’m the only one who really needs it.

Group 2: The Steady Utilities

While the ambitious platforms struggled, my small, simple utilities found a quiet, steady rhythm. These aren’t trying to change the world, just fix a small annoyance.

Advanced AI Actions

• What: One-time purchase iOS utility app to expose LLM providers through Siri Shortcuts.
• How it went: Around $15 MRR (amortized). Considering that it’s not a subscription app, I would say this is a success. I am glad people get value out of it. Active dev time was about a week, and then a few days here and there to fix bugs.
• Status: Full support going forward. Maybe migrating it to a full free-but-with-unlock app and adding a paid provider option to see if people can be converted to monthly payments.
• The Lesson: People will pay for simple utilities that solve a specific problem on their device.

Masked Email Manager

• What: Utility iOS app for managing Fastmail’s Masked Email feature. Already built this before I quit my job, but I’ve been adding more features such as Siri Shortcuts support to it.
• How it went: Around 5-6 unlocks each month. I think that’s okay considering how niche it is, and being one-time purchase. Active development time of around 1 month in total.
• Status: Full support, will continue as one-time unlock utility app.
• The Lesson: Niche utilities can work if they draft off a larger platform’s userbase (Fastmail).

Group 3: The Consumer Bets

This is where I saw the most actual traction—solving problems for regular people, not just other coders.

Fix My Japanese

• What: Japanese grammar and sentence structure correction through AI, created back when the bleeding edge davinci model was the smartest thing around. Comes as web service and iOS app that’s free with subscription.
• How it went: $14 MRR, 6 active subscriptions, 180 DAU, 700 WAU. Project is steadily growing but financially a failure. Active dev time is a couple months at this point, started way back.
• Status: Active growth. As long as it pays for itself it will stay alive. I will continue to try and integrate more paid features to see if some of those 700 WAU can be converted to paid users.
• The Lesson: Steadily growing but effectively a failure financially. It’s a great free product, but getting people to pay for additional functionality is hard when the free tier is “good enough”. Nowadays people use ChatGPT which can do 80% of what Fix My Japanese does, further making it unlikely for people to pay.

Quickshot Photo Editor

• What: Quickshot is an AI-powered photo editor for iPhone (Edit photos through words, not tools). It started when photo editing with AI models became better and viable. It’s using a clever pipeline of models and AI upscaling to make targeted edits without destroying the original photo.
• How it went: 6 active subscriptions, $16 MRR. Financially a failure, but one of my apps with the most potential.
• Status: Active development. This app has potential and I will put more time into it after my current focus is completed.
• The Lesson: Despite fewer updates, this made more money than the others. It has the most potential because it appeals to a broad consumer base, but nowadays also competes against ChatGPT which is a hard uphill battle.

Fun stuff (The Playground)

• esimdb: E-Sim comparison site using providers I frequently use and vouch for.
• Desks for WeWork: Native iOS app for managing WeWork bookings.
• The Enabler: Companion that always agrees with you, no matter what.

What I learned

But financials aren’t the only things I managed to learn. I learned a lot of things on the way that hopefully will help me keeping my focus going forward more sharp.

1. Always build with the monetization strategy in mind

Very obvious first learning, but never build something without knowing how to monetize it. I am pretty good at keeping at that already, but some leftover apps (mainly Fix My Japanese) are fighting with the problem of converting free users to a paid tier.

1.1 But, keep a free tier around because most people don’t want to pay money

Getting paid users is tough. There’s a lot of mental steps involved to getting someone to pay for your thing, but you’ll want those users as well for growth. Offer some kind of free tier that is heavily restricted in usage and clearly pushes to the upgrade path.

2. SaaS is hard and competitive

Microfn taught me that building dev tooling and hosting services is extremely hard. The field is highly competitive with the big players (like Cloudflare workers, Firebase, Google App Engine, etc) being hard to out-maneuver for user acquisition. Can’t run ads and outbid those companies, which leaves organic growth.

3. Most of my stuff is too niche, focus on broad consumers instead

Yeah hard truth. Mailwire is a great transparent email proxy, but who in the world besides me needs this? Microfn is a great platform, but most people don’t need this. MCP Nest does exactly what it ought out to do, but the audience is tiny.

The tech world is a tight community, better to focus on broad consumer apps instead (Quickshot, Fix My Japanese) where there’s more room for niche players and lower customer acquisition costs.

4. You need luck

Some apps like Quickshot that haven’t received updates still made more money than a lot of other apps that actively received new versions. Even the best idea needs the right timing and the right bit of luck to grow.

5. Indie hacking is lonely

Another hard truth: indie hacking and working on stuff alone can feel lonely fast.

It’s a strange paradox. I have the ultimate freedom, I can travel anywhere, work from a café in Tokyo or a WeWork in Sydney, and take a random Tuesday off to go hiking. But that freedom disconnects you from the rhythm of the rest of the world.

My friends work full-time jobs. They can’t do spontaneous trips. They have “work stories” and office drama that I can no longer relate to. There were times when I was so wired into my work, in a foreign city, that I forgot where I actually was.

Having coworkers or a community is nice, and my closest equivalent to that are currently the WeWork offices I use for working across the globe. It’s a different kind of lonely, not sad, just… singular.

6. Marketing is a skill I desperately need to learn

Building a great product is only half the battle—maybe even less. I’ve realized that I have a major blind spot when it comes to marketing. Some of the services I built are technically solid and solve real problems, but I have no idea how to get them in front of the right people.

As a developer, it’s easy to fall into the “build it and they will come” trap. But they don’t. Marketing is a skill just like coding, and it’s one I need to get better at if I want any of these projects to actually succeed.

Going forward

So what is next for me in 2026?

I have no regrets and no plan to stop (for now), but I will focus on broader consumer apps and keep the dev-centric services in maintenance mode with minimal time put into them.

Specific goals for 2026:

• Reach $500 MRR by end of year
• Focus on 2-3 core projects instead of spreading thin across 7+
• Be more data-driven: implement proper analytics with NewRelic and Posthog dashboards to see what works and what doesn’t
• Double down on Quickshot and Fix My Japanese - the projects with the most traction

I may need to start winding down some things in 2026 to keep my focus tight. That still feels like shooting your baby, but as my focus becomes thinner, this will become necessary.

If you’re interested in following my indie hacking journey, you can find me on Twitter/X or check out my projects at david.coffee. Always happy to chat with fellow indie hackers about the ups and downs of this journey.