Back to blog

IndieBob opens to indie developers — and its AI cannot invent your features

·5 min read
IndieBob opens to indie developers — and its AI cannot invent your features

Registration is open. IndieBob is a growth workspace for indie developers — content, first-party analytics, attribution, campaigns and revenue around one project — and this post is about the part I care most about getting right, because it is the part every other AI writing tool gets wrong.

Ask any of them to write about your product and it will produce fluent, confident, publishable prose containing features you have never built. Not because it is broken: because it is doing what it does. It has never seen your code. Given a product name and a gap where a specific should be, it fills the gap. The output is not a lie so much as a plausible average of every product that has ever had a name like yours.

That failure mode is not a nuisance for an indie developer. It is the whole risk. You are one person whose only real asset is that people believe what you say about your software.

The mechanism, not the promise

Every AI content tool says its output is accurate. What matters is what happens structurally when the model does not know something, so here is IndieBob's answer in the order the code runs it.

Product Facts is a per-project corpus. Three sources, one row each (project_facts, unique on project + source):

  • curated — a facts sheet you write by hand in project settings. What the product does, what it does not do, pricing, platforms, and the numbers that are allowed to be cited. It is your word, so it is the strongest source and it wins the character budget.
  • website — imported from your registered domain. The importer fetches /, /pricing, /features, /docs and /faq, strips them to text and bounds them.
  • readme — imported from a public README or CHANGELOG by URL. GitHub blob URLs are rewritten to their raw form for you.

Imported sources record when they were fetched, and the panel shows each source's size and freshness, because a grounding corpus that quietly went stale is worse than none.

The corpus is deliberately small: 4 000 characters per source, 9 000 across all of them. That bound is not a limitation I am apologising for — it is the point. This is a prompt, not a knowledge base. It is the paragraph the model is allowed to know about you.

The corpus is injected into every content prompt. Blog drafts, briefs, social posts, email copy, meta descriptions. There is one seam — the project context string that every content prompt already received — so grounding rides the existing thread rather than living in a checklist somewhere that a new prompt template can forget to consult. A prompt cannot opt out of it by accident.

With it go rules that override style. In the model's words, before it writes anything:

The PRODUCT FACTS above are the ONLY source of truth about this product. Never state a capability, feature, integration, price, or limitation the facts do not support. If the outline asks for something the facts do not cover, write around it or insert [VERIFY: what needs checking] on its own line instead of guessing. Never invent statistics, benchmarks, customer stories, testimonials, or named customers. No number appears unless it is in the facts.

The [VERIFY] marker is the part that makes this an engineering answer instead of a wish. The model is not being asked to be more truthful; it is being given somewhere to put a gap. Confabulation is what happens when a generator has no legal way to produce "I don't know" — so the fix is to make not-knowing a valid, visible, greppable output. A draft that comes back with four [VERIFY] lines has told you exactly which four sentences need a human.

And when a project has no facts on file at all, the model is not left to improvise. It is told so explicitly, instructed to describe the product only in the one line of general terms it has, and to leave [VERIFY: …] where specifics belong.

The claim check

Grounding constrains what gets written. The claim check tells you what actually got written.

One button in the editor. It takes the draft body and the facts corpus, extracts every specific claim the article makes about your product — features, capabilities, integrations, platforms, pricing, performance, any number — and returns each one as grounded, with a short supporting quote from your facts, or unverified. Deliberately excluded: general industry statements, opinions, claims about other products. Those are not what this is for.

The panel reads All 9 claims grounded ✓, or 3 of 12 claims unverified with the three flagged and the rest showing their evidence.

Three design decisions worth stating plainly, because they are the difference between a conscience and a compliance checkbox:

It never blocks publishing. Unverified is not a verdict on truth — your facts sheet is probably incomplete, and half of what it flags will be things you know perfectly well and simply never wrote down. The tool's job is to make you look, not to make the decision. A gate you cannot override gets routed around within a week.

It is not metered against any plan allowance. Every other AI action in IndieBob draws on a monthly count. This one does not, on purpose: charging for the safety check

Share this article

Stay up to date

Get the latest insights on indie software growth, marketing tactics, and building profitable projects.

No spam. Unsubscribe anytime.