How Should Indie Developers Choose What to Build?

Ever since I read Unscripted and dozens of Starter Story case studies, I have kept an eye out for SaaS ideas in everyday life.

A lot of my friends run small and mid-sized businesses. When they tell me about something going wrong at work, I start breaking down their workflow in my head. Is there a piece of this I could solve with the technology I know?

One recent conversation turned up an idea: regulatory compliance plus RAG. I started a proof of concept right away and read up on RAG and compliance while I coded.

Claude Code kept the early part moving. Then the RAG pipeline and the architecture came together, and I saw that the engineering was probably the easiest part of the problem. The hard part came after. Where does the data for the golden set come from? If I cannot understand a compliance case myself, how do I judge whether the system answered it correctly? Who runs the evals?

Those questions all landed in the same place. Whether the system could become a business came down to how well I understood the domain, and whether I could turn that understanding into something reliable.

With software I have a fairly clear way to check whether it works. Law is not like that.

Both fields need someone to be responsible in the end. But a legal answer with its sources attached still needs a qualified person to judge it and sign off on it. I was not confident that technology alone would get me over that barrier.

That was where I started asking myself: did I pick the wrong problem to begin with, or is this a barrier I could cross with enough skin in the game?

While I was stuck there, recruiters on LinkedIn sent me a few AI-native SaaS openings. I had not even finished sorting out my thoughts before I was back in another cycle of interview prep. The project went on the shelf.

The interviews gave me a look at how better-funded startups handle the same domain knowledge problem.

Legal AI startups, for instance, have enough money to put lawyers and consultants on the team directly. Some of those experts are shareholders. The people supplying the domain knowledge carry the risk and share the upside if the product works.

That much capital and organization is out of reach for indie development. But the way those teams work is close to the environment I want. Engineers and domain experts sit in the same problem for a long time, and both are on the hook for whether the product ships.

What I value most in that setup is that engineers get to watch how the problem is defined, how the answers are checked, and how the product finally reaches the customer.

If I got the chance to join a team like that, I could use my engineering skills to turn what the domain experts judge into systems that stay reliable and can be maintained. I would also want to stay in one problem domain long enough to get past the requirements: why we are building this, what customers actually care about, which technical tradeoffs make sense. Domain knowledge builds up through that.

The interviews also sent me back to my own assumptions about indie development.

I had pictured the path as a straight line. Find a potential pain point. Build enough domain knowledge. Add technical skills and execution, and make a proof of concept. Once I know someone needs it, work on distribution.

I really did think I could walk those steps in order. Then I walked into a field I did not know, and found that domain knowledge does not install like a technical package the moment I need it.

Some knowledge takes years. Some information never circulates in public at all. More frustrating: I may not be able to tell whether a problem suits an indie developer until I already understand the problem.

So how does an indie developer find a pain point worth years of attention? How do we build enough domain knowledge to solve it, then get the product in front of people willing to pay?

With those questions in mind, I looked into three indie developers I had come across recently.

Three indie developers, three paths to choosing what to build

Jesse Hanley, Takuya Matsuyama, and Jannis Fedoruk-Betschki have very different backgrounds and very different products. What they share is that each one built on the career he already had, and ended up with a business that one person or a tiny team can run for years.

I will introduce each product first, then break down the three cases with four questions:

• What problem does he solve?
• Why was he able to solve it?
• Where do his customers come from?
• How long did validation take, and where is the product now?

1. Bento: Jesse Hanley

Bento is an email deliverability and marketing automation platform. Most of its customers are SaaS and ecommerce companies.

I found Jesse through X. Marc Lou had gone to Japan to hang out with him, and I got curious enough to dig around for who he was. I came out of it with a pile of podcast interviews.

I like how Jesse sounds on those podcasts. Practical, sincere, warm. His values keep surfacing in the answers. He cares about his family and his quality of life, so he keeps the business small on purpose and saves his time and attention for the people and things that matter to him.

What problem does he solve?

The problem came out of Jesse's own years of running email marketing.

A team writes good content and builds the whole funnel, and the mail still lands in spam. Sender reputation, DNS authentication, some other sender on the same shared IP. The automation editors in existing tools are often painful to use, and the price climbs steeply with contact count even when most of the list never receives anything.

Bento did not start as an email product. It started as a website personalization service. Jesse added analytics and tracking so business customers could see whether the personalization was doing anything, and after launch he noticed customers cared more about the visitor data than about personalization itself. That raised a question. If Bento already knew what a visitor had done, could it act on that behavior? He added email automation, then kept going into SMS, transactional email and deliverability.

Why was he able to solve it?

Bento sat almost exactly on top of Jesse's work history. Early in his career he ran systems, marketing, and operations for Australian health supplement retailers and ecommerce companies. Later he had his own marketing agency, handling SEO, ads, and email campaigns for clients. He was Bento's ideal customer for years before he built anything.

He taught himself Rails and React and did the full stack himself. When something went past what he could do, he brought in more experienced engineers and learned from the code they committed.

Where do his customers come from?

Bento's customer acquisition reuses what Jesse did at the agency: help people online, for free, for a long time.

For three or four years he kept a Calendly link on his Twitter profile so anyone could book a call with him. He would spend an hour or more helping someone untangle a problem and sell them nothing at the end. Some of those relationships turned into customers years later. Sometimes a friend finally lost patience with Mailchimp or Klaviyo and remembered Jesse.

Once customers sign up, he keeps the word of mouth going by doing support himself. A customer paying US$30 and a customer paying US$3,000 can both reach him on Discord. He runs demos, helps with migrations, records tutorial videos.

Small customers kept introducing bigger ones, and support itself turned into one of Bento's main acquisition channels. In recent years he has added podcasts, sponsorships, and interviews to stay in front of the customers he wants.

How long did validation take, and where is Bento now?

Going by Jesse's own retrospectives, Bento never had a clear round of market validation up front. He was still running the agency, and part of why he started was that he wanted to write code and become a developer. He brought in Andrew Culver, whom he had met in Tokyo, and spent the first year stuffing analytics, a bit of email and automation into the product. He later described it as trying to build everything for everyone, and getting nowhere.

He went all in on Bento only after selling the agency during the COVID pandemic, when he needed to rebuild his cash flow.

That was when he noticed the part users actually responded to and kept using was email. The product started narrowing from there.

By time to market validation, Bento is the slowest of the three products here. Jesse built it on the side of the agency for about three or four years before it was complete enough that customers could treat it as a replacement for their existing email provider. Nothing got validated in a few weeks. He kept reading clues in how customers used the product and narrowed the positioning slowly.

The slowness bought him a deep understanding of the product. A Tropical MBA interview from March 2026 described Bento as a business with annual recurring revenue over US$1 million, which puts monthly revenue at around US$83K at minimum. Jesse has not published an exact MRR. Most of the time the company is still him plus a few part-time collaborators.

2. Inkdrop: Takuya Matsuyama

Inkdrop is a cross-platform Markdown note-taking app built for software engineers. It works offline, syncs to the cloud, encrypts end-to-end, and takes plugins.

I found Takuya while picking an editor for Peak Pals. He is one of the few Japanese indie developers I know of. He also runs his [blog](https://www.devas.life/) on Ghost, and as a Ghost user myself, that made him feel closer to home.

He works hard at building an audience on YouTube. In his own Japanese-accented English, he talks about his life and the problems he keeps running into. A recent video about burning out in the AI era hit home for me.

What problem does he solve?

The starting point was simple. Takuya could not find a note-taking app he wanted to use. That is pretty much why I built Peak Pals.

He kept his development notes in Evernote, which handled code snippets and Markdown badly. Web apps died offline. Editors that synced over Dropbox were slow and ate CPU. The rest were either too thin or so fiddly he did not want to open them every day. He went through the options, found nothing he could live with long term, and built his own.

Why was he able to solve it?

Inkdrop's domain knowledge started with Takuya himself. He was the target user. He wrote code every day and took technical notes every day.

He had been building software since he was a teenager. He worked at Yahoo! Japan, contributed to open source, and freelanced for years. Before Inkdrop he made a music app called Walknote. It reached 130,000 users and made no money. That failure taught him downloads and a working business are two different things. So Inkdrop charged a subscription from day one, and he narrowed the audience to developers willing to pay for their tools.

Where do his customers come from?

Early customers came almost entirely from writing. Takuya kept posting about how he built the app, how he got his first customers, and what running a one-person SaaS is like, then shared those posts on Hacker News (HN). At the peak, HN sent about 90% of new users. He never pitched the product on his blog. He wrote honestly about what he got right and what he got wrong, and readers and word of mouth built up from there.

After 2018 the weight shifted to the devaslife YouTube channel. He filmed his life as a developer, the tools he used, his side projects, with Inkdrop showing up naturally along the way. By 2024, YouTube was sending 70 to 80% of new users at one point. He later set up a Discord for paying users and ran online meetups. Those channels may not bring in many new customers, but they give core users a reason to stay.

How long did validation take, and where is Inkdrop now?

Takuya did not run user interviews or put up a waitlist before building. He finished off his client work, gave himself three months for an MVP, and dropped a closed beta on Hacker News in June 2016. The post hit the front page and pulled in more than 1,000 beta sign-ups in a short time. Those users filed bugs and asked for features. The usage data showed that some of them really did open it every day. That was Inkdrop's first market validation.

The product started charging in October 2016. Six months later it had US$1,000 in sales and 30 paying users. About a year after launch, MRR hit US$1,361. Growth was not explosive, but it was enough to show that people would keep paying for a product this niche.

The most recent hard number Takuya has given is that Inkdrop held above US$10K MRR for more than three years. In his 2025 retrospective, posted in early 2026, he also said new customer growth slowed and revenue came in below 2024, because he spent the year on v6 and did less marketing. So what we can say is that Inkdrop sat above US$10K MRR for years. We do not know its exact 2026 number..

3. Magic Pages: Jannis Fedoruk-Betschki

Magic Pages is managed hosting for Ghost blogs. You get a working Ghost site in minutes and never touch a server, an update, a backup, a CDN, or email settings.

Jannis is the indie developer who has impressed me most lately, because we have actually talked. Two months after I first contacted him, I was paying him money.

I found him on the Ghost forum, digging through old threads about search. I wanted to build a Ghost RAG side project. Jannis was all over that forum answering questions, and he had released a search package he wrote himself. My reaction was: this guy is awesome. He has to be a serious geek. I kept reading and found out he also runs a Ghost hosting company, alone.

Our first real contact came from a bug. The localized pricing page on the Magic Pages site had me convinced the annual plan cost US$4,480. It was NT$4,480. Almost half of Ghost(Pro).

I wrote to him about the localization problem. He replied in 30 seconds and shipped the fix in 10 minutes.

Then I worked out how to migrate, asked him a few more questions, and started a trial. Every time I emailed support, he answered me himself, quickly, whatever time it was where he lives. His execution and his enthusiasm got me. I moved my site over.

Later I found his blog, which is a treasure. He writes about what is hard about building this business and what it has cost him personally. My favorite post is the story of how he turned down an offer from Apple. That choice is part of how he got here.

What problem does he solve?

Ghost is open source and already does writing and newsletters well. What is left is how you host it. Host it yourself and you own Docker, databases, backups, DNS, and email settings. Pay for managed hosting and the price climbs as you add custom themes, a CDN, or advanced features. Most creators only want to write, and instead they end up learning technical details they will touch once every two or three years.

Newsletter pricing is the other difference. Ghost(Pro) prices by a site's total member count, free members included, and lets you send as much email as you want. Magic Pages puts no cap on members and includes 10,000 emails a month, then charges US$5 for every extra 10,000. A small blog that does not send much email fits the second model better and pays less to send.

Jannis did not set out to run a hosting company. In early 2023 he wanted a server to park a batch of Ghost sites on, and a base to sell custom Ghost development from. He presold 15 lifetime plans at US$249 each. The product did not work yet. The first customers paid anyway.

Why was he able to solve it?

That trust came from what he already knew. Jannis started out in customer support and built a support team from nothing at a startup in 2020. The company suddenly had hundreds of customers and was too small to keep hiring. That is when he started learning web development, because he wanted to solve support and operations problems with code.

He went on to work as a full-time web developer, made templates for Carrd, and fixed website problems for customers. Magic Pages sits right where customer support, web development, and Ghost overlap.

Then the sites he hosted went from 30 to 100 to 600 to more than 1,400, and he had to fill in infrastructure too. Docker, Kubernetes, distributed storage, CDNs, email deliverability. Almost all of it came from something breaking while he was running the service. You do not get that from building a proof of concept.

Where do his customers come from?

Magic Pages got its first customers on Twitter.

Jannis talked about the idea in public before the product had a name. The earliest customers came from his own network, plus people who had bought his Carrd templates or had him help them out. Once that first group was using it, word of mouth did the work. By mid-2023 he saw customers recommending Magic Pages to their friends and realized this could be more than a side project.

He still gets customers the same way: his own name, his existing customers, and the Ghost community. On his blog he writes openly about infrastructure failures and the postmortems, about cost changes, about what is hard in the business. He has been a fixture in the Ghost forum and on Reddit for years. When someone asks where to host a Ghost site, his customers answer before he does.

That enthusiasm is why I am a paying customer. I used to email Ghost(Pro) support when my admin panel was crawling. A normal reply took two or three days. Once, when their staff were on holiday, I waited more than seven days. Almost every email I send Magic Pages comes back from Jannis in 15 minutes. When a creator's site is breaking, that gap decides how much they trust their host.

How long did validation take, and where is Magic Pages now?

Magic Pages was validated before the product was finished. The first 15 presales brought in about US$3,500, which covered the first server and part of the development. Roughly three months passed between the presale and the first sites going live. In February 2024 he added monthly and annual plans next to the lifetime plan, and seven months later he hit US$1,034 MRR.

That is the last exact MRR he has published. In May 2025 he said only that Magic Pages had been out-earning his full-time job for a while. As of August 2026 the website shows more than 1,400 creators. Customers are spread across monthly, annual, and lifetime plans, old pricing, and multi-site accounts, so you cannot work out the current MRR from the site count. But a one-person side project became a three-person team in three years. It is past its first commercial validation.

Back to my problem of what to build

After studying these three cases, I looked again at my own experience building Peak Pals.

Like Takuya-san, I was the most direct user of Peak Pals. I knew how the workflow should run and which problems to solve first. After launch I used the product every day, and beta users kept sending me feedback. The loop built itself. The domain knowledge was already sitting in my life, so I never had to go out and get it.

Where I got stuck was the business model and distribution. I wrote about that in my Peak Pals V1 launch retrospective.

The compliance RAG project ran the other way round. I could see a solution through an engineering lens. But I could not run effective LLM evals, I had no contextual data, and I could not stand behind my own results.

Before I looked into these three indie developers, I talked with my friend Marcus about how to make up for the domain knowledge I was missing.

He offered something I had never seriously considered. If domain expertise is what I lack, why not pay for it? Hire domain experts, either as ongoing advisors or by the hour.

He also pointed out that I get to choose how big the problem is. One person cannot build what a team can build. If I aim at a product one person can finish, the consulting bill for it should stay affordable.

The same logic works in reverse. If a company needs a room full of domain experts to assemble context out of experience that nobody writes down, then it was probably never a one-person problem. Joining that company would not remove those knowledge barriers either.

Listening to him, I realized I had jammed two questions into one. How do I acquire domain knowledge? And is this problem even suitable for an indie developer?

I agree that a consultant could teach me an industry's structure, its existing workflows, its regulations and its common problems, and teach me fast. That would save me a lot of wrong turns.

What I am less sure about is the experience that is hard to measure but shapes product sense. And all the unknown unknowns.

We did not arrive at a clear answer that day. Marcus did pull apart the two questions I had tangled together. Breaking a problem down from first principles has always been one of his strengths. Because he raised the idea, I kept digging, and that research eventually became this article.

The asymmetry between engineering and domain knowledge

Researching these three developers reminded me of something. Both Jesse and Jannis had outsourced engineering work. Jesse brought in Andrew Culver to help develop Bento, and read the code alongside him until he had picked up Rails and React. Jannis paid an outside team to build custom email functionality in the early days. Neither of them let go of the product. When something blew up, they could jump in and fix it themselves.

Their paths from nontechnical backgrounds to SaaS founders changed how I thought about the problem.

What they handed off was feature work and customer support. Both have a clear scope. You can define the job and check the result when it comes back. That is the same reason LLMs can now write so much of the code. Engineers are good at writing specs, and code is about the easiest output there is to verify.

Domain knowledge and business logic do not come in that shape. Which problems are worth solving, who to serve, who will actually pay: they kept all of that themselves. AI speeds up building the software foundation. It cannot hand you product sense.

So for an indie developer, the path into a product can run in the other direction:

Nontechnical domain expert → AI and engineering capabilities → Domain-specific SaaS

For an engineer walking into an unfamiliar field, a consultant can help with the catching up. To really understand the field, picking an environment that keeps you exposed to it for years, or finding a partner whose incentives line up with yours, still looks like the more practical way in.

Caring about the pain behind the problem

Looking back at these three, they share one more thing. They genuinely care about the problem they are solving.

Jesse ran a marketing agency. He knows exactly what a painful email tool costs a client, and what happens to their results and their trust in you when the mail lands in spam.

Takuya writes technical notes every day. A bad tool wears down his development energy a little more each day.

Jannis came from customer service. He cares whether creators get stuck on a technical problem, and whether someone is there to catch them when it happens and explain the fix in language they can follow. I have been on the receiving end of that.

More than once I felt my questions were a bit abrupt, and Jannis answered every detail anyway, holding nothing back. You cannot fake that with a support playbook. It is the attitude toward building products that I admire and want for myself.

None of these three sat down one day and thought, "Oh! Time to look for pain points!" and then worked out where the product should go. The pain was already sitting in their lives and their work.

They had spent long enough in a field to know which parts were genuinely annoying, and to spot the friction everyone had simply gotten used to. Used to it does not mean unfixable. When one of those problems bothered them enough that they wanted to build the solution with their own hands, the product grew out of it slowly. Organically.

Caring is not enough on its own, of course.

They also needed to keep shipping, and to read feedback well enough to correct course and pivot when it was time.

What I want to compound

Writing this got me thinking about a different question. Over the next few years, what do I want to compound?

As an engineer, I am used to stacking technical skills. LeetCode, system design, framework knowledge. The path is clear and so is the feedback. I put in the hours, learn the material, and then either pass the interview or ship the thing.

Those skills still matter to me. I want to keep my hands on the newest tools and keep getting better at complex problems.

But engineering skill on its own does not get me a product that solves a real problem and leaves me proud of the result. That also takes an understanding of the users and the domain.

Engineering got Peak Pals to production. It could not tell me what the product should solve, which features to build first, or whether the thing actually helped anyone. That part still comes down to how well I understand the problem.

So product sense is what I want to compound on purpose.

I want to sit in one problem space long enough to know which problems are worth solving, which requests are noise, what customers will pay for, and where the product should grow next.

I cannot read my way there, and I cannot cram it into one sprint. It comes from talking to the same users again and again, fixing things for them, and finding out which of my assumptions were wrong. Domain knowledge and customer insight are the parts of a good product I cannot shortcut.

Which is why spending my working years inside a domain I care about and would stay in for years still looks like the best use of my time. The team matters as well. I want one that lets engineers talk to customers, sit in on defining the problem, and see what our product decisions did.

AI already speeds up the coding. I would rather spend the attention it frees up on the users and the product, then feed that back into my technical judgment.

Life outside work will pull me into other problems anyway, through the people I meet and the communities I stay in. I may not need to block out time and force myself to "explore domain knowledge."

For now, the practical version is smaller. Pay attention to the things that keep bugging me, especially the ones I care enough about to want to fix myself. Keep stacking technical skills in the meantime. Then when a problem I care about that much shows up, I can start testing a solution right away.