I have a graveyard of side projects. Landing pages with no product behind them. Half-built apps that already had a pricing page. A few that got far enough to earn a logo before they stalled. They died for different surface reasons, but underneath there was one cause. I built every one of them to sell.

The projects that lived started somewhere else. I built rifts.to because I wanted to run live polls in a room without routing an audience through a logged-in dashboard from one of the big polling platforms. I’m building HARDMODE because I want to train with my cousin who powerlifts in California, and nothing off the shelf fit the way we wanted to do it. I’m building Innerplatz because I’m actually doing the emotional work with my coach and my therapist, and I wanted a tool shaped around that work instead of one designed to be sold. I run this blog on Jekyll because I wanted to own the words and the URL instead of renting them. None of them started with a business model. They started as things I needed.

It took me longer than I’d like to admit to take that pattern seriously.

Selling-first builds for a person who doesn’t exist

When you build to sell, you start with an imagined customer. You sketch their pain, their budget, the objection they’ll raise on the call. Then you build backward from the pitch.

The trouble is that the imagined customer is generous in every way a real one isn’t. They forgive the rough edges. They use each feature exactly the way the demo shows it. They never wander into the workflow you forgot to handle, because you were busy designing the pricing tiers.

Real users are not generous. They find the unhandled path in the first thirty seconds. But you don’t have a real user yet, so you keep refining the product that only the imaginary one would tolerate.

Using-first hands you a brutal user on day one

Build something for yourself and you get a tester who can’t be charmed by a nice landing page and quits the second the thing becomes annoying. You.

I notice every dropped keystroke in a tool I use daily. I notice the extra click. I notice the feature that works on Monday and breaks on Thursday. I can’t demo my way past my own friction, because I’m the one stuck living in it.

That loop beats a stack of customer interviews. Interviews tell you what people say they’d want. Using your own product every day tells you what actually breaks under load.

The demo trap

Selling-first development optimizes for the demo, and the demo is a lie you tell on purpose. It’s the happy path with the lighting set just right.

Features get ranked by how they read in a deck, not by how they survive a normal week. You build the impressive thing that wins the meeting and skip the boring thing that keeps the product alive. The roadmap fills up with screenshots.

Using-first development optimizes for Tuesday. Nobody’s watching. The product just has to work while you get real work done. That’s a harder test and a far more honest one.

Selling-first feels like progress, and that’s the trap

The cruel part is that building to sell feels productive. The pricing page, the waitlist, the landing copy, the logo. You get the dopamine of shipping without shipping anything anyone uses. You can spend a month on go-to-market for a product that doesn’t work yet, and at the end of it you’ll have a tidy funnel pointed at a hole.

Using-first denies you that comfort. There’s no waitlist to admire. There’s just the tool, sitting on your machine, working or not. The only metric that exists is whether you reached for it again today.

“But you can’t build a business on a tool you only use yourself”

You can, and plenty of people have. Some of the most durable software companies started as internal tools that someone refused to stop using. The founders weren’t chasing a market. They had a problem, solved it for themselves, and then noticed the same problem everywhere they looked.

The order is the whole point. Use first, sell later. A tool earns the right to become a business by being good enough that losing it would sting. If you wouldn’t be annoyed to lose it, no one else will pay to keep it.

Building to sell skips the part where the product gets good and sprints straight to asking for money. That’s why so many of them never get good.

What this looks like in practice

Build the thing you need. Use it every day. Let your own irritation write the roadmap. Ship the unglamorous fixes before the flashy features, because you’re the one who has to live with the bugs.

Once it has survived your own daily use for a few months, then it’s worth asking whether anyone else wants it. By that point you’ll know exactly what it does well, because you’ll have spent that whole time as its harshest critic. The pitch writes itself, because you’re not describing an imagined value. You’re describing your own Tuesday.

The selling can wait. The using can’t.

Build the thing you’d hate to lose, and everything after that is just distribution.