The $1 Test: How I Used Claude to Validate a SaaS Idea Before Writing Any Code

Here’s a question I ask myself before I open a code editor: if I put this idea in front of a total stranger right now, would they pay me one dollar for it? Not a survey answer, not a “sure, I’d probably use that” — an actual dollar, out of their own pocket. If the answer is no, no amount of clever engineering is going to save the idea later. So instead of spending four to six weeks building an app, pushing it through a distribution loop, and then finding out the hard way that nobody wants it, I’ve started running ideas through Claude first to see if they survive contact with reality. In this post I’m walking through exactly how I did that for a real idea of mine — a gym workout tracker — prompt by prompt, question by question, including the part where the idea didn’t make it.

Why I Run Every App Idea Through a $1 Test First

The dollar amount is almost beside the point — it’s the bar, not the business model. I picked one dollar specifically because it’s low enough that price can’t be the excuse. If a total stranger with no relationship to me isn’t willing to part with a single dollar for whatever I’ve built, that idea has failed the sniff test, full stop. There’s no follow-up question about pricing tiers or freemium funnels that fixes a “no” at the one-dollar level.

But flip it around, and the same logic gets exciting fast. If one stranger will commit a dollar, that’s not proof of a business, but it’s proof of a pulse — enough confidence to go find the next 999 people just like them.

That $1,000 in monthly recurring revenue isn’t the finish line. It’s the floor you build on. From there you scale, you raise price, you add tiers. But you only get to have that conversation if the very first stranger says yes. So the exercise in this post is a joint one: figuring out, live, how to prompt Claude so it actually helps you find a dollar-worthy idea instead of just cheerleading whatever you type in.

Quick Context on Where I’m Coming From

For anyone landing on this for the first time — I’m an ex-Microsoft product leader and a technology entrepreneur on my second founder journey. Building apps and services is very much a hands-on habit of mine, but my full-time focus right now is running my own business. On the side, I coach PMs and do SaaS and app teardowns, which is really just an extension of the same instinct: pull ideas apart and see what’s actually load-bearing.

The Two Things You Need Before a Stranger Pays You a Dollar

Before I even open a prompt window, there are two things that have to be nailed down, because without them Claude — or any tool, honestly — will just hand you generic mush back.

Number one: a razor-sharp definition of who this person is. Not “busy professionals,” not “moms at work,” not “sales professionals looking to save time.” Those are demographic buckets, not people. I’m talking about someone specific enough to have a name — a Joe, an Alice, a Dana. Number two: their single most painful pain point — the one thing they genuinely cannot go on with their day without solving. If your app or service can solve that one specific pain point for that one specific person, you’ve got something worth testing. Vague personas produce vague ideas, and vague ideas never clear the dollar bar.

Setting Up the Prompt: My Gym-Tracking Idea

To make this concrete, I pulled an idea straight from my own life. I’m in the gym three to four times a week, primarily doing strength training, and I wanted Claude to help me evaluate whether an app that tracks a gym-goer’s strength training — logging sets, monitoring progress, that kind of thing — actually has legs.

Here’s roughly what I gave Claude as a starting prompt: I want to build a service for people in their 30s and 40s who are regular gym-goers doing strength training, to help them track their workout routines. Decide whether a website or an app fits better, and briefly say why. Then give me three clarifying questions before you go further.

That last instruction — asking for clarifying questions instead of a finished answer — is doing a lot of work here. It forces the model to slow down and pull more signal out of you instead of guessing.

From those answers, Claude built out a persona: Dana, a 38-year-old marketing manager who lifts four times a week after work and has been training for six years. Her specific pain point: she currently logs her sets in her phone’s Notes app, but it’s slow to update between sets and nearly impossible to scan later when she wants to know what she lifted last time.

Off the back of that pain point, Claude suggested a stripped-down lifting log built around one screen: pick an exercise, and it instantly surfaces your last few sessions so you’re not digging through a wall of notes mid-set. Honestly, even as someone who’s lived this exact problem, I thought that was a genuinely useful, tightly-scoped answer. A user persona, a specific problem, and an abstract solution — all from one well-set-up prompt.

Desire Isn’t the Same as Viability

Here’s where it would be easy to stop and start building. I had a persona, a pain point, and an idea that even I found appealing as a gym-goer. But I want to be honest about what that actually is: desire, not viability. I want to build a gym-tracking app. That’s my desire. Whether this specific idea from Claude can survive real market pressure — whether it can actually clear the one-dollar bar — is a completely separate question, and it’s the one that actually matters.

So before going anywhere near a build, there’s a short list of questions I consider essential for pressure-testing any idea Claude hands back: Has this persona already used other tools in this category? If so, what were they using them for, and why did they stop? That last question — why someone switched away from a purpose-built tool into something as bare-bones as the Notes app — is often where the real insight is hiding. It tells you whether there’s an actual wedge to build into, or whether you’re about to compete head-on with tools that already do the job well.

Pressure-Testing the Idea: Three Follow-Up Questions

With that in mind, I went back to Claude with three specific follow-ups instead of asking it to just “build the idea out more.”

That last answer is the quiet killer. It means the simplest version of my idea — plain tracking — isn’t a gap in the market. It’s the exact thing people already tried and walked away from.

The Verdict: My Gym-Tracking App Didn’t Pass the $1 Test

Put those three answers together and the picture is pretty clear. The feature I wanted to lead with is already a premium feature elsewhere, which means it doesn’t clear the bar as a free MVP hook. And the simplest version of the idea — just logging sets — is very likely the exact thing Dana already tried and abandoned in favor of the Notes app. That’s not a promising signal. That’s a strong sign this specific idea, as scoped, is not going to get a stranger to hand over a dollar.

This is what I mean by feature triaging: using pointed follow-up questions to eliminate the weak parts of an idea before you’ve written a single line of code, rather than after you’ve sunk weeks into it. If I still wanted to pursue gym tracking as a category, the next move wouldn’t be to build — it would be to go dig for a gap the existing three players genuinely haven’t addressed yet.

Why Failing Fast With Claude Beats Building Blind

My gym-tracking idea didn’t survive the test. I’m not calling that a wasted session, though — quite the opposite. The entire point of this exercise was to find out, cheaply and quickly, whether an idea is worth a dollar, and if it is, whether it can realistically scale to 1,000 users and $1,000 in MRR as a starting point. Getting a clear “no” in twenty minutes of prompting is a dramatically better outcome than getting the same “no” after four to six weeks of building, followed by another few weeks pushing it through a distribution and marketing loop.

Kill it at the source, and move on to the next, better idea. That’s a much better way to fail than finding out in the marketplace.