Survey the Battlefield First: Competitor Research in One Day with AI
AI cut the cost of building tenfold — and the cost of research tenfold too. A repeatable competitor-research workflow for solo builders: map the field in the morning, run 12 comparison dimensions in the afternoon, ship a one-page decision by night — and why its greatest value is telling you what NOT to do.

The biggest risk for a solo builder was never technical
Here's a hard truth: most vibe coding projects don't die because the tech was too hard — they die because five better versions already existed by the time you shipped. You spent three weeks heads-down building an AI notes app, only to discover on launch day that Notion AI and two indie hackers already own that space, and your version has nothing to distinguish it except being uglier.
My take: AI cut the cost of "building from 0 to 1" tenfold, and it also cut the cost of "researching from 0 to 1" tenfold. You've been enjoying the first half; most people never touch the second. Solo builders who once couldn't afford consultants or reports can now map an entire battlefield in an afternoon. Anyone still skipping research isn't lazy — they're betting three weeks on a hypothesis that one hour could have disproven.
This article gives you a workflow I use myself: one day, three phases, one page of decisions. Research in the morning, compare in the afternoon, decide at night. The goal isn't an MBA-style report — you'd never read that twice. The goal is to answer three questions: should I fight this battle? Which segment? And why would I win?
The one-day schedule: lock the rhythm before the method
Research's biggest enemy isn't too little information — it's paralysis from too much. So step one isn't opening a browser, it's setting a deadline for the research. My schedule:
- Morning (3 hours): draw the competitor map — find 5–8 real competitors, covering direct competitors, indirect competitors, and "the free workaround users settle for."
- Afternoon (2.5 hours): run the comparison dimensions — score every competitor on a fixed grid to find the gaps and their soft spots.
- Evening (2 hours): ship the decision — one page: build or not, where to cut in, and what the differentiation is.
Notice the deliberate friction in this design: every phase has a hard deliverable, and you stop when time's up. Research is a means, not the end — stop the moment you can make a decision; anything beyond that is procrastination in a respectable coat.
Phase 1: let AI draw the competitor map (morning)
First, have AI enumerate the battlefield. The prompt must be specific to your scenario — not a hollow "find me competitors":
I'm building "a lightweight invoicing tool for indie developers
with automatic Stripe reconciliation."
List: 1) direct competitors (same kind of product);
2) indirect competitors (same problem, different approach);
3) what users do today instead (including free workarounds
like spreadsheets and manual work).
For each: website URL, one-line positioning, target user.
Only list products that really exist; mark anything
uncertain as "unverified."
The three-layer structure is the key. The most common blind spot in research is only looking for direct competitors: your real opponent is often not a similar product but the workaround users already tolerate — that spreadsheet, that old printer, that group chat. AI doesn't know who your users are; you have to explicitly ask for the "workaround" layer in the prompt.
Then comes the anti-hallucination step — the most expensive lesson in AI research: open and verify every single URL the AI gives you, by hand. Models will confidently invent products that don't exist, quote outdated pricing, and attribute one company's features to another. My routine: AI outputs a table, I open each site one by one, and dead or wrong ones get crossed out. Verifying 8 competitors takes about 40 minutes — the 40 minutes in this whole workflow you can least afford to skip.
While verifying, do one more thing: open each competitor's pricing page and changelog (or blog). The pricing page tells you how it makes money and where the free tier draws the line; the changelog tells you what direction it's been pushing toward — a product untouched for three months and one shipping weekly are two completely different opponents.
Phase 2: the 12 comparison dimensions (afternoon)
With the map drawn, move to comparison. Don't freestyle it — freestyled comparisons always end in useless "they're all pretty good" verdicts. Use a fixed grid of 12 dimensions and record each competitor against every one:
- Target user: who is it really for? The same people you want?
- Core features: only the 1–3 things it genuinely does well — not a feature list.
- Pricing & free tier: how much, and where the free plan draws its line — the free tier's boundary is your entry point.
- Onboarding friction: how many steps to sign up? Card required? Cold-start experience determines its acquisition cost.
- Claimed differentiation: its own answer to "why pick us"?
- User sentiment: real reviews on G2, Capterra, app stores, and X — with special attention to 1–2 star reviews.
- Shipping cadence: what shipped in the last three months? A stalled product is an opportunity; a sprinting one is a warning.
- Team & funding: headcount, money raised — this decides how long it can burn and how many mistakes you can afford.
- Acquisition channels: SEO, content, community, PLG? Where it shows up tells you where the users are.
- Open ecosystem: API? Integration marketplace? Closed products leave seams for newcomers.
- Technical implementation: rough stack, if visible — a read on how hard it is for them to change.
- Your gut score: 1–10 — if you were its user, would you stay?
Let AI fill in the grid, but #6 (user sentiment) and #12 (gut score) are yours to do. AI can't read the emotion in a bad review, and it can't make the "would I use this" call for you. Those two rows carry the most signal in the entire table.
Mining bad reviews: the goldmine everyone ignores
Let me expand on #6, because it's the highest-ROI step in the whole workflow. A competitor's 1-star reviews are an unmet-needs list voted on with real money.
The method: feed each competitor's bad reviews (app stores, G2, X rants — all fair game) to the AI and ask for three things: cluster the complaint themes, count how often each appears, and find the ones complained about for over a year that the vendor never fixed. That last category is the goldmine — a long-unfixed complaint means it's either technically hard or commercially inconvenient to fix; either way, it's your window.
Example: if three competitors' reviews keep repeating "exports are weak" and "support takes three days to reply," and you're a solo builder who can reply same-day and nail exports — you already have two ready-made differentiators, no brainstorming required. That's the point of research: differentiation isn't invented; it's mined from competitors' bad reviews.
Phase 3: the one-page decision (evening)
With everything gathered, output one page. Copy this template:
[DECISION] Build / Don't build / Build it differently
[ONE-LINE POSITIONING] ___ (product) for ___ (user);
unlike ___ (competitor), we ___ (differentiation)
[SEGMENT TO CUT INTO] ___ (a specific user type + scenario)
[WHY WE WIN] 1.___ 2.___ (must come from review mining
or the dimension grid — "better UX" doesn't count)
[WON'T-DO LIST] 3 things explicitly off the table this time
[BIGGEST RISK] ___ (if this turns out true, kill the project)
The template's sharpest lines are the last two. The "won't-do list" forces you to admit limited resources — the solo builder's biggest delusion is "I'll do it all." The "biggest risk" forces you to write down your kill condition — writing down when to stop before you start is ten times easier than stopping on willpower later.
If you finish the template and can't fill in the "why we win" lines, congratulations — the day wasn't wasted: you just spent 7 hours avoiding three months of sunk cost. "Don't build" is the most valuable decision there is, and most people need three months to reach it.
Once AI makes information free, what's scarce isn't information — it's judgment. Competitor research ends not with knowing your rivals better, but with knowing yourself better: clearly enough to say "these three things, I won't do."
Three anti-patterns: how research goes bad
Finally, the three ways I've seen research rot most often — vaccinate yourself in advance:
- Research paralysis: competitor #9 and #19 won't change your decision. Five to eight is enough; beyond that you're using "preparation" to dodge "starting." A hard one-day cap is the cure.
- Research as placebo: if your conclusion is "the market is huge, opportunities everywhere," you did no research. A good conclusion is specific and even a little painful: "segment X is owned by Y; I can only cut into Z." Painless research is self-comfort.
- Studying competitors but not users: competitor research answers "what are rivals doing," but not "will users pay for my version." The first move after research: take the one-pager to 3 potential users for 15 minutes each — AI can't do that part for you.
One closing line: in the AI era, the information gap between a solo builder and a full team has been erased. The remaining gap is simply who's willing to spend a day seeing the battlefield clearly before building. That day is the cheapest insurance you'll ever buy.
Related articles

Prompts in vibe projects live in code strings, admin text boxes, and docs — changed live, version unknown when things break. This guide shows how to treat prompts like code: a prompts/ layout, YAML frontmatter, semantic versioning, PR reviews, canary rollouts with one-click rollback, plus an evals baseline — and a real war story: one added sentence cost 12 points of classification accuracy.

The faster AI writes code, the more review matters. Four layers: diffs for logic (boundaries, errors, concurrency — plus auth, payments, SQL, encryption, secrets), runtime for behavior (type checks, lint, security scans go green first), AI for first-pass screening (a second model reviews, humans read only flagged parts), humans for the final call (AI never clicks merge). Includes commit norms, PR template, branch protection, rollback plans.

Your site is live but Google can't find it? A hands-on SEO playbook for vibe-coding indie hackers: how to pick a rendering strategy, a technical checklist item by item, content without the farm, and a 30-day action plan to execute. Be worth indexing first.