Projects vs. Products: Know When to Stop Building for Yourself

The boat was always the easy part. The sign is the decision.

Every weekend, my feed fills with "I built this in 3 hours with AI."

Most of them are genuinely cool. Most of them should never become products.

I've built things that should have stayed projects. Tried to turn them into products anyway. Sometimes I caught it early. Other times, I let it ride too far. Those lessons stick. This piece is the one I wish I'd read before I made those calls.

A Saturday morning market in Cape Town with real businesses and passion projects side by side — A Saturday morning market in Cape Town. Real businesses and passion projects, side by side.

The art of the possible

Projects are how you explore what exists before anyone has decided it should.

No constraints. No customers. Just curiosity finding its edges. You build because you want to see if it can be built. You learn something. You move on, or you don't. Both are fine.

That work matters. Most great products started as projects somebody refused to kill. But that's not the same as saying every project deserves to survive.

AI has collapsed the cost of starting a project to nearly zero. What used to take a weekend sprint takes an afternoon. Which is great, except the pile of half-finished, over-extended side projects is growing faster than ever. I wrote about why that framing matters in AI Is Just a Consultant.

The question isn't "can I build this?" anymore. Everyone can build something. The harder question: should this become a product?

What actually makes something a product

A product is not a project that's ready. That's the trap.

A product is a project that has developed an opinion. An opinion about what actually needs to exist. For whom. Why someone would pay for it, rely on it, or be worse off without it. And why you are the right person to own that relationship.

That last part is the one people skip.

Building for yourself is one thing. Building for a stranger who depends on your work is something else entirely. The moment someone else's workflow runs through what you built, the rules change. Your curiosity becomes their expectation. Your weekend hobby becomes their Tuesday morning.

Most people haven't figured out who their product is for before they try to productize. They're still answering the project question ("can I build this?") when the product question is completely different: "do enough people need this badly enough to justify what it costs me to keep it running?"

Two market stalls side by side — one branded business and one passion project — Cape & Co. has the branding and the card reader. Mama Zandi has the conversation and the jars. Both are at the market. Only one is running a business.

The farmers market test

Think about what actually happens at a farmers' market.

You've got real businesses running alongside people who love what they make and just want to share it. Both exist at the same table. Both can even make money. But the hobbyist selling sourdough and the bakery testing a new market location are not doing the same thing, even if the loaf looks identical.

Here's what I think is actually happening at most of those stalls: the makers are looking for validation. They're not running a business yet. They're testing a question. Should this become a product? A busy Saturday morning feels like a signal. The compliments feel like traction.

But there's a gap between "people loved this" and "people will pay for this reliably, at scale, when I'm not there to tell the story." The farmers market compresses that feedback loop in a way that feels real but isn't always honest.

The same thing happens with AI side projects. You ship something. It gets a few hundred users. People say nice things. The GitHub stars tick up. It feels like a signal.

Maybe it is. But you have to be honest about whether what you're running is a farmers' market stall or a business.

What the shift actually costs you

Here's the part nobody talks about when they post the "I shipped this in a weekend" thread.

A project is fun because it's yours. You set the scope. You walk away when it stops being interesting.

A product takes that option away.

Curiosity becomes an obligation. Tinkering becomes support tickets. That creative Saturday-morning problem you solved for yourself becomes a Monday-morning support queue for someone else's slightly different version of the same problem.

The project that felt fun in January becomes a burden by April. Managing users who found it through a tweet you forgot you sent. Fixing edge cases on setups you've never seen. Explaining why it breaks when someone uses it in a way you never intended.

None of that is bad work. It's just different work. And most people don't price it honestly before they make the leap.

Fun project crossed out with my problem now written underneath — "Fun project" crossed out. "My problem now" written underneath. We've all been here.

The decision framework I use

Before I productize anything now, I ask four questions.

1. Who has this problem besides me?
Not "who might find this interesting." Who actually has the same problem, in the same context, with the same constraints?a If I can't name five people immediately, it's a project.

2. Would they pay for it, or just use it for free?
Free users give you a signal. Paying customers give you a business. Big difference. A lot of AI tools have learned this the hard way: tons of traction, zero revenue, no path to keeping the lights on.

3. Am I willing to own the support relationship?
This is the one that kills the most ideas for me. If someone relies on this and it breaks at 11 pm on a Friday, am I the one fixing it? If the answer is "yes, and that feels fine," it might be a product. If I'm already looking for ways not to be that person, it should stay a project.

4. Does the work the product creates align with the work I want to do?
A tool that automates your own workflow is fun to build. A tool that requires you to manage other people's automations is a different job. Make sure the job the product creates is actually the job you want.

If you can't answer all four honestly, you're not ready to productize. That's not failure. That's the project doing its job.

Comparison chart showing project traits versus product traits — The comparison that matters. Most people are still on the left side thinking they're on the right.

Projects are not failures

I want to be clear.

Projects are where you learn. They sharpen the instincts that tell you what's actually worth building. Some of my best professional work started as something I built with no intention of shipping.

The goal isn't to productize everything. The goal is to be honest about what you're building and why.

The farmers' market is real. People make real money there. Some grow into real businesses. But some of the best stalls at my local market have been there for fifteen years and are clearly just a way for someone to spend their Saturday doing what they love and covering their costs. That's not a failure. That's a choice.

The problem is when you let the energy of the farmers' market convince you that you should open a restaurant.

What's next

Next week, I'm getting into the Build vs. Buy vs. Partner decision. The practical version of this same question applies to your AI stack. Once you've decided something should exist as a product, you still have to decide whether you should be the one building it.

This piece is the philosophical setup. Next week is the operational one.

If this landed for you, forward it to someone who's been talking about shipping their side project. They'll either thank you or hate you. Either way, you've done them a favor.

What's the last thing you built just to see if you could? Hit reply. I read everything.