If you build it, they won't come—and that's precisely the point

A lot of developers—especially in this era of vibe-coded tools—build apps and then struggle to gain adoption. I’ve built some myself. Watching the pattern up close, I think there are really only two honest paths once you decide to build something.

Build for others¶

Path one is the obvious one: you’re building a product. Not a side project, not a toy—a thing you intend for others to use, pay for, and come back to. That’s the classic product development cycle. You start with the opportunity, understand the problem, figure out who your product serves and how, and work the full loop: finding customers, getting them excited, and making sure they actually pay. If that’s the path you’re on, you probably shouldn’t start with engineering. You definitely shouldn’t start by vibe-coding a prototype before you know whether the problem is real.

Build for yourself¶

Path two is the one I want to defend: you build it just for yourself. That sounds limiting. If you’re going to spend the time, why not open it up to others? But I think there’s something genuinely interesting about building something that fits only you. It’s like tailoring your own clothes—they fit better than anything off the rack, and that’s the entire point.

For most of software history, you couldn’t do this. Coding was tedious. Learning it took years, through engineering school or the hard way. We saw the same pattern on the design side—Photoshop required a license, then mastery, then figuring out how to export properly. Sketch made it lighter. Figma made it collaborative. Now Claude does most of the scaffolding for you.

Beyond the factory model¶

The software industry was built on a factory model: produce for the mass market, sell to the mass market. That’s still the default assumption when someone says “I’m building an app.” But the factory model isn’t the only model anymore. The barrier to building for yourself has collapsed, and the output is no longer embarrassing. You don’t have to ship a purple-gradient AI-slop homepage. Custom tools can be beautiful because they’re tuned to one person’s taste.

If you take this path, you’re not a mini-startup. You’re a craftsperson. You’ve built up taste, preferences, and enough understanding of the tools to mold them to your own hand. The tool might serve only you. Maybe a few friends. That’s enough. Tools are enablers—they scale and accelerate you. A tool that accelerates one person is still a tool doing what tools are for.

I’ve built two of these recently.

The notes app¶

The first was a notes app. I’d been obsessed with the idea for a long time—dreams, requirements, strong opinions. I was literally using other notes apps to take notes about the notes app I wanted. Extremely meta. I finally sat down with Claude Code, spent about half an hour figuring out Firebase so I could sync across devices, and the rest came together in under three hours. I got exactly what I wanted: tags by project, tags by person, markdown formatting, image support, the whole thing. It’s simple. It’s mine. And I’m still using it, which is the real test.

Andrej Karpathy floats a more extreme version where you don’t even need a notes app—you just hand everything to Claude and trust it to remember. Maybe. For now, the point isn’t that mine is better than Notion or Obsidian. The point is that it was built in three hours for an audience of one, and it serves that audience perfectly.

The to-do app¶

The to-do app is the more interesting one. I’ve bounced through most of them—Todoist, Things, OmniFocus. I was a longtime Todoist user, but at some point the product started drifting. Features I didn’t want. Opinions I didn’t share. Historically, when a SaaS tool drifts away from your use case, you’re stuck with it—or you leave for another one that will eventually drift too. One afternoon, I stopped being stuck and built my own.

Eighty percent of it is generic to-do app—projects, lists, tasks, scheduling. Nothing novel. But the remaining twenty percent is specific to me: summaries of how I’m spending my time, breakdowns by project, insights that help me see the bigger picture. I’ve added weekly and monthly planning views that tell me whether the tasks I’m checking off are actually advancing my goals, or whether I’m just generating the feeling of productivity.

That last part is the real unlock. Most to-do apps are checklists. You cross things off and feel accomplished, but sometimes you’re just spinning—doing a lot, going nowhere. I wanted a tool that forced me to see whether the day was laddering up to the week, and the week to the month. My version isn’t perfect. It’s janky on mobile, so I use it on desktop. It politely calls me out when I’ve scheduled something important and then quietly avoided it. If I ever wanted to ship it, I’d have a long list of things to fix—but I’m not shipping it, so the list doesn’t matter. And if I ever want to improve any part of it, I can.

So: build for others if you’re building for others. Follow the process. AI probably lets you do it with fewer people and less time, but the fundamentals don’t change—you still have to talk to customers, understand what hurts, and figure out what they’ll pay to make it go away.

But if you’re building for yourself, you skip all of that. You ask what you want. You shape the tool over time to fit your needs. And you get something we’ve never really had before: software made for one person, reshaped every time that person changes. There’s something beautiful in that. For most of software history, engineering was too hard for this to be a reasonable move. It isn’t anymore.

This is a new era of custom tool-building—and some of the best tools being built right now are the ones that were never meant to ship.