Everyone says "build for yourself." Here's the signal that actually proves someone else will pay.

You scratched your own itch. Built the thing you wished existed. Used it yourself for weeks, maybe months. It works. You're proud of it.

And now you're staring at a launch that nobody seems to care about.

The Data Point of One

"Build for yourself" is canonical startup advice. Paul Graham preaches it. DHH built Basecamp from it. Many successful founder stories seem to start with "I needed this, so I made it."

The advice is sound. It's also dangerously incomplete.

You needed this product. That's a fact about you. It tells you nothing about the market. A single data point describes your life, your workflow, your frustrations. The market hasn't spoken yet.

You've been shipping for weeks. You believe in what you built. Belief keeps you building. It won't tell you whether you should.

So where do you look?

Watch the Hands, Not the Mouth

Communities are full of signals. Most founders read the wrong ones. There's a hierarchy here, and it matters.

Wishes sit at the bottom. "Someone should build an app that does X." This means almost nothing. People wish for things constantly. Wishing costs zero effort, which is exactly what it's worth as a signal.

Complaints are one step up. "I'm so frustrated with X." Better, but dangerous. Complaints in communities often point you toward feature requests for products that already exist (going after the same market can work, but that's a different play). That person wants their current tool to suck less. You'd end up building someone else's feature request.

Workarounds are the gold. "I've been using [tool never meant for this] combined with [other tool] to kinda sorta do [thing]."

When someone describes a workaround, they've already crossed every threshold that matters. They identified the problem. Accepted it's solvable. Invested real time. And settled for a brittle, clunky solution because nothing better exists.

In chemistry, activation energy is the minimum energy needed to start a reaction. In human behavior, it's the gap between "this annoys me" and "I'm actually going to do something about it." Most problems never cross that threshold. People tolerate extraordinary amounts of friction.

When someone has jury-rigged a solution from three tools that were never designed to work together, you're looking at someone who already behaves like a customer. They've just been paying with time and frustration instead of money.

The Adjacent-Space Tell

Don't only look in your exact niche. Look sideways.

If you built a tool for photographers, check what videographers are doing. Event planners. Wedding coordinators. When people in adjacent spaces are hacking together the same kind of solution from completely different tools, the problem transcends your personal perspective. It's structural.

Wade Foster, before co-founding Zapier, was doing client work where people kept asking for integrations between apps that didn't talk to each other. Then he went to the support forums of Evernote, Salesforce, and Dropbox and found the same pattern: people describing specific workflows they'd duct-taped together with manual processes and custom scripts. No single community was asking for "Zapier." But dozens of communities were independently cobbling together the same kind of brittle solution.

Nathan Barry saw it too, before building ConvertKit. Professional bloggers were stringing Mailchimp together with WordPress plugins, third-party landing pages, and manual subscriber tagging to create email sequences Mailchimp was never designed to support. The tools weren't broken. They just weren't built for what creators needed. The bloggers had already proven the demand by frankensteining together their own version of the product that didn't exist yet.

In both cases, the founders didn't discover demand by asking people what they wanted. They discovered it by watching what people were already doing with the wrong tools.

But those stories reveal something else. The adjacent-space check doesn't just validate that demand exists. It tells you what people actually value about the solution.

A photographer jury-rigging an asset workflow cares about organization. A wedding coordinator cobbling together the same kind of system cares about speed under pressure. Same structural problem, different workaround shape, because each group filters the problem through what matters most to them.

I've shipped products in courier logistics, food delivery, children's book publishing, and software. In every case, people were already solving the problem with the wrong tools before I showed up. But the workarounds looked nothing alike. Courier clients' workarounds pointed at reliability. Food delivery workarounds pointed at speed. Bookstore workarounds pointed at discovery. The workaround's shape tells you what the product needs to solve first. Miss that, and you build a technically correct product that doesn't match what anyone was actually paying to fix.

Run the Test

Before you build (or before you panic about a quiet launch), run what I call the duct tape test. Look for three things:

  1. Multiple people solving the same problem with different wrong tools. If everyone's using the same tool, you're looking at a feature request for that tool. If they're each reaching for different tools, the problem is real and unaddressed.
  2. Solutions that work but barely. Functional enough to keep using. Fragile enough to curse at. People won't abandon something that's "fine." They will abandon something held together with spreadsheet formulas and a prayer.
  3. Independent invention. They came up with these workarounds on their own. When multiple people independently hack together the same kind of solution without coordinating, you're seeing a genuine pattern.

All three present? You have something better than a hunch. You have evidence of urgent, unmet demand. These people already want what you're building. They just don't know you're building it yet.

What Workarounds Won't Tell You

Workaround shapes tell you what to prioritize. They don't tell you how much to build.

The duct tape test proves the problem. It doesn't prove your solution.

Someone stringing together three tools isn't asking you to replace all three. They might love two of them. What they hate is the glue, the manual step, the copy-paste between systems, the thing that breaks at 2 AM.

Build the complete replacement and you're fighting adoption friction against tools they already like. Build the bridge and you're solving the part that actually hurts.

This is the misread that keeps showing up in indie hacker communities. Someone spots a real workaround, gets excited, and builds a general replacement around it. Six months later they're competing with established tools instead of connecting them. The workaround showed them the pain. They just diagnosed the wrong organ.

Read the workaround closely. What part does the person curse at? What part do they actually seem comfortable with?

The seams tell you more than the surfaces.

Urgency Is the Filter

Real problems are common. Urgent problems are rare. And products survive on urgency.

The duct tape test filters for urgency automatically. Nobody jury-rigs a solution for a mild inconvenience. The very existence of a workaround proves the pain crossed the threshold where tolerance turned to action.

There's a harder case, though. Some workarounds are so embedded in how people work that nobody describes them as workarounds anymore.

Spreadsheets doing database jobs. Browser tabs pinned as dashboards. Manual processes that someone runs every Monday morning "because that's just how we do it."

The friction is invisible because it's been there longer than anyone's been paying attention. These are the demand signals that don't show up in community posts, because nobody thinks to complain about the air they breathe.

If you can see one of these, you're looking at demand so deep the market doesn't know it has it.

This won't help you if you're inventing a new category (nobody was jury-rigging an iPhone in 2006). But at the indie scale, you're discovering demand, not creating it. And workarounds, visible or buried, are the clearest proof that demand already exists.

The next time you think "I need this, so others probably do too," pause. Go find the duct tape. Look for the spreadsheets doing jobs they were never designed for, the browser tabs held open as makeshift dashboards, the twelve-step Zapier chains held together with hope.

If nobody's cobbling together a workaround, the problem might be real. But the urgency isn't there yet.

And urgency is everything.

Rabbit Hole