Editorial Standards
How every card on SaaS Compass is made
Every card must pass these standards before it's published. Cards that don't are rejected or rewritten until they do.
1. One buyer, not a market
Every card names one specific buyer persona — their exact role, company context, and the moment the pain occurs. We reject cards that target “developers,” “small businesses,” or “teams” without a concrete qualifier. If you can't picture the person's job title and the Tuesday afternoon when this pain hits them, the card fails.
“For developers who want to automate workflows.”
“For a solo backend engineer at a 10–50 person B2B SaaS who spends 3+ hours per week manually syncing customer data between Stripe and their internal CRM because their ops team has no budget for a full iPaaS solution.”
2. Named gaps, not vague complaints
The competitive gap must name what the incumbent product literally cannot do for this persona — not that it's “too expensive” or “too complex.” Vague gaps produce vague products. If you can't say exactly what the existing tool fails at for exactly this person, the card fails.
“Zapier is too expensive and has too many features that solo founders don't need.”
“Zapier cannot trigger on partial webhook payloads or run conditional branching without a $69/month plan — which rules it out for solo engineers who need a one-off Stripe → Notion sync with no recurring cost.”
3. Specific channels, not categories
Every roadmap Validate phase names real communities where this buyer is reachable — actual subreddits, Slack workspaces, Discord servers — not “online forums” or “social media.” If we can't name the room, the card is not ready.
“Post in relevant forums and developer communities to find early users.”
“Post in r/selfhosted, the Laravel Discord #side-projects channel, and the Indie Hackers ‘Show IH’ section. These are the three places where backend engineers building solo SaaS products actively compare tooling.”
4. Stack choices with rejected alternatives
Every tool in the recommended stack includes the alternative we considered and the concrete reason it was rejected for this specific product. “We chose X over Y because Z” — not just “X is a great tool.” Generic endorsements are not useful to founders who need to make real tradeoffs.
“Use Supabase for your database — it's a great tool with a generous free tier.”
“Supabase over PlanetScale: PlanetScale removed its free tier in 2024 and charges per row read, which makes it prohibitively expensive for this product's read-heavy webhook log pattern before revenue. Supabase's free tier supports 500MB of storage with no read-cost surprises.”
5. What happens to cards that don't pass
Cards are generated with AI assistance, then reviewed against these standards by a human editor. Cards that fail any criterion are rewritten or discarded. We publish fewer cards than our competitors on purpose — because a catalog of 30 sharp ideas is more useful to a founder than 300 vague ones.