Skip to content

Profiles overview

The 314 Mandatory items aren't all relevant to every project. A solo internal tool doesn't need multi-region active-active replication. A consumer recipe app doesn't need SOC 2 evidence collection. A B2B SaaS does need both. Profiles are the filter.

Each profile is a YAML-fronted Markdown file under core/profiles/ that names: which roles fire critical / supportive / minimal, which Mandatory items activate, which Conditionals trigger and why, and which Conditionals are deferred with their re-trigger conditions.

Browse the canonical profile files at core/profiles/ on GitHub.

The 6 V1 profiles

Profile Active items V1 gaps Best fit
b2b-saas-web 264 0 Multi-tenant Postgres web SaaS, paid users, mid-scale, GDPR or SOC 2 in scope. Densest profile.
b2c-saas-web 248 0 Consumer web app, large user base, low ARPU, high abuse surface, marketing-CDN concerns.
marketplace 246 4 Two-or-more-sided platform with payment flow between users (escrow, split, payout).
ai-wrapper 230 5 LLM is the core value prop or central feature on the user path (RAG, copilot, AI search).
mobile-app 220 5 Mobile-first product (iOS / Android / RN / Flutter) — backend-side coverage only.
internal-tool 184 0 Employee-only admin/ops console, relaxed availability, internal SSO. Lightest profile.

Profile descriptions

B2B SaaS Web (264 items, 0 gaps)

A subscription web application sold to other businesses, built on a shared-schema multi-tenant Postgres backend, with paid users (mid-scale: ~10k–100k DAU), an availability commitment in customer contracts, and at least one compliance vector (GDPR, SOC 2, or both). Examples: Linear, PostHog, Cal.com (commercial tier), Vercel (control plane), Notion, Retool.

The densest profile. All 7 roles fire critical. Multi-tenancy with RLS is the keystone; idempotency, region-aware data model, and build-vs-buy boundaries are Day-1 commitments. Worked example: HiringDesk.

B2C SaaS Web (248 items, 0 gaps)

A consumer-facing web application with a large user base (often hundreds of thousands to millions), low average revenue per user (free tier or $5–$30/month), single-tenant-per-account or shared-tenant model, marketing-site CDN concerns, and high abuse surface (signup spam, credential stuffing, scraping). Examples: Spotify, Duolingo, Strava (consumer tier), Headspace, Notion (free tier), Figma (free tier), Substack readers.

Anti-abuse cluster + CDN/WAF + RUM are elevated concerns relative to B2B. Multi-tenancy is simpler; abuse defense is harder. Worked example: PantryPal.

Marketplace (246 items, 4 V1 gaps)

A platform connecting two or more user types (buyers and sellers, hosts and guests, riders and drivers, freelancers and clients), with payments flowing between them, often with escrow / split / payout mechanics. Examples: Airbnb, Etsy, Upwork, Fiverr, TaskRabbit, Reverb.

Multi-sided complexity adds payments, dispute, and identity items. 4 V1 gaps honestly flagged: trust & safety policy, escrow state machine, two-sided rating system, search ranking. The marketplace example walks them in detail. Worked example: BoardSwap.

AI Wrapper (230 items, 5 V1 gaps)

A web/mobile product where one or more LLMs are the core value proposition or a central feature on the user path. Examples: Cursor, Perplexity, Notion AI, Granola, Glean, Cal.com Assistant. Excludes products where LLM is a side feature only used internally.

Triggers prompt-injection defense (security 49) and the LLM input/output handling pattern. 5 V1 gaps honestly flagged under no-ML-Engineer-role: cost monitoring, RAG security, output filters, eval harness, prompt registry. Worked example: CaseLens.

Mobile App (220 items, 5 V1 gaps)

A mobile-first product (iOS / Android / cross-platform via React Native or Flutter) backed by a web-callable API. This profile covers ONLY the backend that serves the mobile clients. The mobile-platform-specific items are NOT yet in V1.

5 V1 gaps honestly flagged under no-Mobile-Engineer-role: push notification security, App Store / Play Store policy hooks, on-device storage encryption, deep links / Universal Links, certificate pinning + attestation. Worked example: ShelfTrack.

Internal Tool (184 items, 0 gaps)

A web application used only by employees / contractors of the building organization, never exposed to public internet end-users, with relaxed availability targets (99% acceptable, not 99.9%+), authentication via internal SSO/SAML/OIDC, and a smaller user count (typically <500 users). Examples: internal admin dashboards, ops back-office tools, customer-support consoles.

Critical principle: "internal" does NOT mean "unsafe". Most security items still apply. The relaxations are operational (multi-region, status page, canary releases) — not security.

8 explicit operational skips with documented ADR-numbers. Security stays full. Worked example: OpsConsole.

How profile resolution works

The plugin's profile resolver is a 5-question flow when context is ambiguous:

  1. Who pays? End-consumers (B2C), other businesses (B2B), neither — internal users only (internal-tool), users of a marketplace (marketplace), users of an AI product (ai-wrapper).
  2. What's the primary surface? Web, mobile, both — mobile-first.
  3. Is an LLM on the user path? Yes (probably ai-wrapper or layered onto another profile), no (other profile).
  4. Is multi-tenancy in scope? Shared-schema with tenant_id (B2B), per-account (B2C), N/A (internal-tool).
  5. Are payments flowing between users (not just to you)? Yes (marketplace), no (other profile).

When auto-resolution is confident, the plugin prints the resolved profile + the triggering signals. When it's not, it walks through the 5-question flow. Ambiguous never auto-resolves.

You can also pass an explicit profile: /vibecodingisold:init --profile b2b-saas-web.

Multi-profile projects

Some projects span multiple profiles legitimately:

  • A B2B SaaS with an embedded LLM copilot triggers b2b-saas-web AND ai-wrapper. Run init twice (once per profile) and reconcile the two artifacts; the union of items applies.
  • A marketplace with an internal admin console — the customer-facing surface is marketplace, the admin surface is internal-tool. Two PLAN-REQUIREMENTS.md files in two paths is the canonical pattern.
  • A consumer mobile app with a B2B sales-team tier later — start mobile-app, plan to re-run as b2b-saas-web when the second tier ships.

The 8 Numerical Contracts hold across profiles. The cross-references ensure items don't conflict across profiles.

V2 profile roadmap (named, not promised)

These are profiles V2 should add. None are scoped or dated; they're named so contributors can propose work.

  • iot-device — physical devices with intermittent connectivity, OTA updates, attestation, fleet management.
  • developer-tool-cli — CLIs, libraries, SDKs distributed via npm / PyPI / Homebrew with telemetry-as-config concerns and supply-chain integrity.
  • chrome-extension — manifest v3, host permissions, cross-origin posture, store-review hooks.
  • embedded-saas-widget — chat widgets, support widgets, analytics snippets — third-party-script considerations dominate.

Profile proposals are welcome via GitHub Discussions. They touch every integration, so they're V2 work, not V1.x.

Where the canonical profile files live

Each core/profiles/<profile>.md file contains:

  1. YAML frontmatter (type, profile, generated_at, mandatory_items_count, optional v1_gaps_flagged).
  2. One-paragraph profile definition with example products.
  3. Worked-example link.
  4. Active roles section with weighting (critical / supportive / minimal) and one-sentence rationale per role.
  5. Mandatory items section, grouped by role, each item with a one-line rationale for why it activates in this profile.
  6. Conditional items section with named triggers.
  7. Deferred / Flag-and-Defer items section with re-trigger conditions.
  8. (For profiles with V1 gaps) Honesty section listing what's missing and why.

Read them directly: core/profiles/ on GitHub.