None of my side projects started with a business model. Every one of them started because I wanted the thing to exist and couldn’t buy it.

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 wanted a tool shaped around the inner work I’m actually doing, not 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.

That order is not the default. The default is to start with the pitch. Pick a market, imagine a customer, sketch the pricing tiers, then build backward toward something worth charging for. It feels like the serious way to do it, and it’s why so much software gets built that nobody opens twice.

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.

Nobody has to file any of that as a bug. I hit it myself, and I’m the one who still has to open the thing tomorrow.

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.

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. I built rifts.to so I could run a poll in a room I was standing in. There was no pricing page and no waitlist. Someone found it through ChatGPT, built a survey on it, and ran that survey with thousands of people across Latin America. I found out from an analytics dashboard, not a sales call. It’s an LLC now, and I intend to make money on it. It started as a need, and I have never once made that work in the other order.

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.

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, you can ask 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.

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