DEV Community: Xavier

Validate your idea (and make money)

Xavier — Sun, 09 Aug 2026 15:07:00 +0000

Do not burn your evenings on the wrong idea.

When you have a job and a side idea, your scarcest asset is not money, it is nights and opportunity cost. The instinct under that pressure is to build, because answering the hard questions feels slower. It is not. Building the wrong thing for three months is the expensive path.

The three questions that actually matter are who pays, how much, and how quickly. A free app with no revenue model is a hobby, not a business, and no amount of nights changes that. Before you burn your evenings, decide whether the thing survives contact with a real buyer and a real price.

ShipFit answers who pays, what to charge, and the smallest thing worth building, with real data, for less than the cost of one wasted evening. Validate before you quit anything, including your sleep.

Nine decisions, real data, and $5 to start.

If you are non-technical low-code founder: You don't need to code. You need to know what to build, who pays for it, and how to launch it. ShipFit makes you decide.

Here is how I handle it now. Before I write a line of code, ShipFit forces nine decisions in sequence: market, buyer, pain, positioning, scope, pricing, demand, launch, and exports. Each one is grounded in real data, real competitor sites, sourced prices, and real reviews, not a confident AI guess. You walk out with a named buyer and their willingness to pay, a defensible price, an MVP scoped to the real hypothesis, a launch plan, and config files ready to paste into Cursor or Claude Code. Or you walk out with a kill verdict and a saved quarter. It starts at $5, with no card to try it.

And it is real data, not AI slop. Every competitor is a real site, every price has a source, every complaint comes from an actual review. A claim you can check beats a paragraph you cannot.

Try it at shipfit.ai. What do you decide before you build?

I stopped getting attached to ideas and started killing them on purpose. Here's the system.

Xavier — Wed, 22 Jul 2026 10:02:11 +0000

I've shipped a lot of side projects. Most went nowhere, and it was almost never the code. Cursor and Claude Code made the code the easy part. They went nowhere because I built the wrong thing, confidently, for six weekends in a row, and only let myself see it after the time was already gone.

That's the trap when building gets cheap. Marc Lou shipped 35 startups, 30 flopped, 5 pay his bills. Everyone reads that as "ship more." It isn't. It's "stop babysitting the one that isn't moving." Getting emotionally attached to one idea is the most expensive habit in this game, because the cost of being wrong is no longer the code. It's the months you refuse to walk away.

So I changed the order of operations. Now, before I open the editor, I force myself through nine decisions in sequence, and each one has to be grounded in something real, not a vibe:

Is it worth building? (Is there an unmet need, or am I just excited?)
Who actually pays? (A named buyer, not "developers.")
What actually hurts? (Which pain is hair-on-fire vs. mildly annoying.)
How do I win? (Where's the gap nobody's serving.)
What's actually V1? (The smallest thing that would change my mind if it failed.)
How do I charge? (A defensible number, not "charge what you're worth.")
Will they pay? (A smoke test before I build, not after.)
How do I launch? (Channels chosen before the build, because the channel shapes the product.)
What do I export? (The decisions written into the config files my coding agent actually reads.)

The point isn't the nine questions. It's the order. Build first and ask whether it was worth building second, and you end up six weekends deep in something you can't bring yourself to kill. Decide first and the kill happens cheaply, on a Tuesday, before there's any code to feel attached to.

When I run ideas through this properly, a real chunk of them don't survive. That used to feel like failure. Now it feels like the quarter I got back.

I eventually got tired of doing this in a messy Notion doc, so I built ShipFit to force the nine in sequence and ground each one in real data — real competitor sites, sourced prices, actual reviews — instead of a confident guess. It exports the config files at the end. Starts at $5 if you want to try it on your next idea.

But honestly the tool is secondary to the habit. What I'm curious about: what's the last idea you should have killed a month earlier than you did, and what finally made you do it?

9 decisions I make before I open Cursor

Xavier — Tue, 21 Jul 2026 14:07:12 +0000

I've shipped a lot of side projects. Most of them went nowhere.

Not because the code was bad. The code was fine. Cursor and Claude Code made the code the easy part. They went nowhere because I built the wrong thing, confidently, for six weekends in a row, and only let myself notice after I'd already sunk the time.

That's the trap nobody warns you about when building gets cheap. Marc Lou shipped 35 startups. Thirty flopped. Five pay his bills. The lesson everyone misreads from that is "ship more things." It isn't. It's "stop babysitting the one that isn't moving." Getting emotionally attached to one idea is the most expensive habit in this game, because the cost of being wrong is no longer the code. It's the months you refuse to walk away.

So I changed the order of operations. Now, before I open the editor, I make myself answer nine questions in sequence. Each one has to be grounded in something I can actually point to, not a vibe and not a confident paragraph from a model that wants to please me. If an idea can't survive the nine, it doesn't get a repo. That kill is not a failure. It's the quarter I get back.

Here are the nine.

Is it worth building?

Not "is it cool." Is there a real market with a real, unmet need. 42% of startups still die from no market need, in an era where you can build anything. Building faster does not fix a demand problem. This is the gate. If the honest answer is "I'm not sure anyone needs this," everything downstream is decoration.

Who actually pays?

Your target market is a hypothesis. Your buyer is data. "Developers" is not a buyer. "Solo technical founders who've already shipped one product that flopped and are staring at the next idea" is closer. Name a specific person, describe when they feel the pain badly enough to pull out a card, and estimate what they'd pay. If you can't name them, you don't have a product problem. You have a buyer problem.

What actually hurts?

The Mom Test is necessary and not sufficient. Talking to users stops you inventing pain, but it doesn't rank the pain. You need to know which problem is a hair-on-fire "I'd pay today" and which is a "yeah that's annoying I guess." Build for the first kind. The second kind is where good weekends go to die.

How do you win?

Every space has incumbents now, including the AI-built ones. So where's the gap? Blue-ocean framing without the two-day workshop: list what everyone in the category competes on, then find the axis nobody's serving. If your only answer to "why you" is "mine's a bit nicer," that's not a wedge, that's a coin flip.

What's actually V1?

Scope creep is how you turn a two-week test into a two-month cathedral. Pick the smallest thing that tests the actual hypothesis from decisions 1 through 4. Not the smallest thing you can build. The smallest thing that would change your mind if it failed. Everything else is a feature you're adding to avoid launching.

How do you charge?

"Charge what you're worth" is not pricing. Van Westendorp for micro-SaaS gets you a defensible number without a $10k study: find the price where it feels too cheap to trust and the price where it feels too expensive to justify, and work the band between. Have tiers, have a reason for each, and know your rough unit economics before launch, not after.

Will they pay?

Intent is not revenue. The cheapest way to find out if people will pay is to ask them to, before you've built the thing. A smoke test: a landing page, a real price, a checkout that captures the click. If nobody clicks buy at $X, you just saved yourself the build. If they do, you've got the only validation that counts.

How do you launch?

There are maybe five traction channels that work for a solo founder and about a dozen that quietly waste your time. Pick your channels before you build, not the night before you ship, because the channel shapes the product. A thing you launch on Product Hunt is not the same thing you grow through SEO.

What do you export?

This is the one that's specific to how we build now. The output of all that thinking shouldn't live in your head. It should live in the config files your coding agent reads. The named buyer, the scoped MVP, the pricing, the positioning, the thing you're actually testing, written into a .cursorrules or a CLAUDE.md so the agent builds the right thing instead of a technically-correct wrong thing.

Your agent is only as good as the context you hand it. Half of .cursorrules files I see are lint rules and formatting. The other half of the context, the half that decides whether you're building the right product at all, never makes it into the file.

The point isn't the nine questions

The point is the order. Build first, ask whether it was worth building second, is how you end up six weekends deep in something you can't bring yourself to kill. Decide first and the kill happens cheaply, on a Tuesday, before there's any code to feel attached to.

When I run ideas through this properly, a decent chunk don't make it. That's not the system failing. That's the system working. The expensive path is the one where you find out after you've built.

So: what do you decide before you build? And what's the last idea you should have killed a month earlier than you did?

I got tired of doing this in a messy Notion doc, so I built ShipFit to force the nine decisions in sequence and ground each one in real data — real competitor sites, sourced prices, actual reviews — instead of a confident guess. It spits out the config files at the end. It starts at $5 if you want to try it on your next idea.

I wired up Cloudflare, RudderStack, Mixpanel, Hotjar and GA. Then I shipped without testing the tracking.

Xavier — Mon, 13 Jul 2026 16:04:03 +0000

I've been a CTO, a CPO and a CMO. I know the stack matters.

So for my first solo SaaS I set it all up properly: Cloudflare, RudderStack, Mixpanel, Hotjar, Google Analytics.

Then I made a rookie mistake. I did not test the tracking before going live.

For two weeks every "what's working" call I made was based on incomplete data. Some events firing twice, some not at all, attribution half wired. I was reading tea leaves and calling it analytics.

Here's the one that stung. One channel converted five times better than everything else. I'd been spreading myself across eight places, thinking reach was the game. It isn't. One channel drove 80% of my signups. I would have known that in week one if my tracking had been solid instead of me spraying everywhere blind.
I also ran paid ads before the tracking was fixed. That is just burning money. If you take one thing from this: fix your tracking before you spend a penny.

The fix was boring. Write the tracking plan first, name every event and its properties, fire them in a staging build, and watch them land in each tool before you point real traffic at anything. I have shipped analytics for products with millions of users. I still skipped it, because when you are solo, everything feels urgent.

The hardest part of doing this alone isn't the building and it isn't the marketing. It's making decisions with incomplete information and shipping anyway. Broken tracking makes that worse, because now even the data you do have is lying to you.

I'm 50, 25 years launching products for big companies, first time doing it solo with my own money. Watching session replays tonight, shipping a new version.

If you're wiring analytics for a launch: what's on your pre-launch checklist to verify events fire correctly? What do you wish you'd caught before go-live?