ship-create 1.0.0

package/templates/docs/product-types/CRM_TEMPLATE.md

@@ -0,0 +1,78 @@
+# CRM Template
+
+A CRM lives or dies on one thing: does it make the next action obvious? Unlike most SaaS, the core unit isn't a "user session" — it's a **relationship over time** (a contact, a deal, a thread of activity). Plan around the pipeline, not the screen. Build the activity log before you build the dashboard — without a reliable history, every other feature (reminders, reporting, automation) has nothing to read from. Launch with one pipeline that matches how your first customer actually sells, not a generic "Lead → Qualified → Closed" template nobody asked for.
+
+## Feature Checklist
+
+- [ ] Contact records (people) with custom fields
+- [ ] Company/account records, linked to multiple contacts
+- [ ] Deal / opportunity records with stage + value
+- [ ] Pipeline view (kanban by stage) — at least one, configurable later
+- [ ] Activity log (calls, emails, notes, meetings) attached to contact/deal
+- [ ] Tasks & reminders (due date, assignee, overdue flagging)
+- [ ] Email integration or logging (manual log at minimum for MVP)
+- [ ] Search across contacts/companies/deals
+- [ ] Filters & saved views (e.g., "my open deals," "stale > 14 days")
+- [ ] Reporting: pipeline value by stage, win rate, activity volume
+- [ ] Import (CSV) and export
+- [ ] User roles (admin, rep, read-only) if multi-user from day one
+- [ ] Notifications (in-app and/or email) for assigned tasks and deal changes
+- [ ] Duplicate detection/merge for contacts (becomes painful fast without it)
+
+## Data Model Starter
+
+| Entity | Key Fields | Relationships |
+|---|---|---|
+| Contact | name, email, phone, title, source, owner_id | belongs to Company; has many Activities, Deals |
+| Company | name, domain, industry, size, owner_id | has many Contacts, Deals |
+| Deal | name, value, stage, probability, close_date, owner_id | belongs to Contact/Company; has many Activities |
+| Pipeline / Stage | name, order, pipeline_id | belongs to Pipeline; has many Deals |
+| Activity | type (call/email/note/meeting), body, timestamp, user_id | belongs to Contact and/or Deal |
+| Task | title, due_date, status, assignee_id | belongs to Contact/Deal (optional) |
+| User | name, email, role | has many Deals (as owner), Activities, Tasks |
+
+## Core User Flows
+
+1. Add contact → enrich with company → log first activity
+2. Create deal → assign stage → move through pipeline via drag/dropdown
+3. Log activity (call/email/note) → auto-timestamp → visible on contact timeline
+4. Create task with due date → get reminded → mark complete
+5. Filter pipeline view → spot stale/at-risk deals → take action
+6. Run report → export pipeline summary for a sales meeting
+7. Import contact list (CSV) → dedupe → assign owner
+
+## Monetization Pattern
+
+Per-seat subscription (price per user/month) is the dominant model — value scales with team size, and usage (deals, contacts) is rarely the metering unit at small scale. Common tiering: limit seats, pipelines, or automation/integrations by plan rather than contact count, since artificially capping contacts feels punitive and erodes trust. Add-on revenue from integrations (email sync, calling, enrichment) is common at scale but skip for MVP.
+
+## Build Order (MVP fastest path)
+
+1. Contact + Company CRUD (the system of record)
+2. Deal model + single pipeline kanban view
+3. Activity log attached to contact/deal (manual entry first)
+4. Task/reminder with due date and "my tasks" view
+5. Basic search + filter
+6. Minimal reporting (pipeline value by stage)
+7. Defer: email sync, automation rules, multiple pipelines, advanced permissions
+
+## Example AI Build Prompts
+
+```
+Build a CRM contact and deal data model in [Postgres/Supabase], with tables for
+contacts, companies, deals, pipeline_stages, activities, and tasks as described
+in the data model below. Include foreign keys, indexes on owner_id and stage,
+and a soft-delete column. [paste Data Model Starter table]
+```
+
+```
+Build a kanban-style pipeline view in [React/Next.js] that shows deals grouped
+by stage as draggable cards. Dragging a card to a new column updates the deal's
+stage via API call. Each card shows deal name, value, and days since last activity.
+Highlight cards with no activity in 14+ days in a warning color.
+```
+
+```
+Build an activity timeline component that shows all activities (calls, emails,
+notes, meetings) for a given contact or deal, newest first, with the ability to
+quickly log a new activity via an inline form (type, body, optional follow-up task).
+```

package/templates/docs/product-types/DASHBOARD_TEMPLATE.md

@@ -0,0 +1,78 @@
+# Dashboard / Internal Analytics Tool Template
+
+A dashboard succeeds or fails on trust in the numbers, not visual polish — if a chart is wrong once, the whole tool gets ignored forever after. Plan the data pipeline (where does truth live, how fresh is it, what happens when a source is late or down) before designing a single widget. Permissions matter more here than in most product types, because dashboards often expose sensitive company data across teams — decide row-level and column-level access rules in the plan, not as an afterthought. Build the data layer and one reliable chart before adding the tenth widget nobody asked for.
+
+## Feature Checklist
+
+- [ ] Data source connections (database, API, CSV upload, or warehouse)
+- [ ] Scheduled or real-time data refresh/sync
+- [ ] Widget library (line, bar, pie/donut, table, KPI number, funnel)
+- [ ] Dashboard builder/layout (arrange widgets, resize, save layout)
+- [ ] Filters (date range, segment, dimension) that apply across widgets
+- [ ] Drill-down (click a chart segment to see underlying rows)
+- [ ] Role-based access (who sees which dashboards/data)
+- [ ] Export (CSV, PDF, image of chart/dashboard)
+- [ ] Scheduled reports (emailed snapshot on a cadence)
+- [ ] Alerting (notify when a metric crosses a threshold)
+- [ ] Caching/performance handling for large datasets
+- [ ] Audit log of who viewed/changed dashboard configs (for sensitive data)
+- [ ] Multi-dashboard navigation (saved views per team/use case)
+
+## Data Model Starter
+
+| Entity | Key Fields | Relationships |
+|---|---|---|
+| Data Source | type, connection_config, last_synced_at | has many Metrics/Datasets |
+| Dataset / Metric | name, source_id, query_or_field, refresh_interval | belongs to Data Source; used by many Widgets |
+| Dashboard | name, owner_id, layout_config (JSON) | has many Widgets; belongs to User (owner) |
+| Widget | type (chart/table/kpi), dataset_id, config (JSON), position | belongs to Dashboard; belongs to Dataset |
+| User | name, email, role | has many Dashboards; restricted by Permission |
+| Permission | user_id or role, resource_id, access_level | belongs to User/Role; applies to Dashboard or Dataset |
+| Alert Rule | metric_id, condition, threshold, notify_channel | belongs to Dataset |
+
+## Core User Flows
+
+1. Admin connects a data source → defines datasets/metrics to track
+2. Admin/user builds a dashboard → adds widgets → arranges layout → saves
+3. User opens dashboard → applies date/segment filter → all widgets update
+4. User clicks into a chart segment → sees underlying detail rows (drill-down)
+5. User exports current view (CSV/PDF) for a meeting or report
+6. Admin sets an alert rule → gets notified when a metric crosses threshold
+7. Admin manages permissions → restricts a sensitive dashboard to specific roles
+
+## Monetization Pattern
+
+If internal-only: no direct revenue — value is measured in decision speed and reduced manual reporting labor (the build is justified by hours saved, not a price point). If sold as a product (analytics SaaS), monetization is typically per-seat or usage-tiered by data volume/number of dashboards/refresh frequency, with higher tiers unlocking more data sources, longer history retention, and advanced alerting/export.
+
+## Build Order (MVP fastest path)
+
+1. One reliable data source connection + one dataset (resist connecting everything at once)
+2. 3-5 hardcoded but real KPI/chart widgets on a single fixed-layout page
+3. Basic date-range filter applied across all widgets
+4. Simple role check (admin vs. viewer) — skip granular permissions initially
+5. CSV export of underlying data
+6. Defer: drag-and-drop dashboard builder, alerting, scheduled email reports, drill-down
+
+## Example AI Build Prompts
+
+```
+Build a data pipeline that pulls data from [Postgres/API source] on a scheduled
+job (every 15 minutes), aggregates it into a metrics table with columns for
+metric_name, value, dimension, and timestamp, and exposes a REST endpoint that
+returns time-series data filtered by metric_name and date range.
+```
+
+```
+Build a dashboard page in [React/Next.js] with a global date-range filter at
+the top and 4 widgets below it: a KPI number card, a line chart (trend over
+time), a bar chart (breakdown by category), and a data table. All widgets
+should re-fetch and update when the date filter changes, without a full page reload.
+```
+
+```
+Add role-based access control to the dashboard app: viewers can see dashboards
+shared with their role but cannot edit layout or data source connections;
+admins can create/edit dashboards and manage which roles can access which
+dashboard. Include a permissions table and middleware that checks access on
+every dashboard load.
+```

package/templates/docs/product-types/DIRECTORY_TEMPLATE.md

@@ -0,0 +1,75 @@
+# Directory Website Template
+
+A directory's entire value proposition is "comprehensive + easy to find what you need" — which means the plan must obsess over taxonomy (categories, tags, filters) before a single listing is entered. The chicken-and-egg problem is real: nobody searches an empty directory, and nobody submits to a directory nobody searches. Solve this in the plan, not in code — usually by seeding listings yourself (scrape/curate the first 50-200) before opening public submissions. Build search/filter and the listing detail page first; claim/submit flows and monetization come after you've proven people search.
+
+## Feature Checklist
+
+- [ ] Listing records with structured fields (name, category, location, description, contact)
+- [ ] Category/taxonomy structure (categories, subcategories, tags)
+- [ ] Search (by keyword) and filter (by category, location, attributes)
+- [ ] Listing detail page (SEO-friendly URL, structured data for search engines)
+- [ ] Submit-a-listing form (public or gated)
+- [ ] Claim-a-listing flow (verify ownership of an existing unclaimed listing)
+- [ ] Admin moderation queue (approve/reject new and claimed listings)
+- [ ] Featured/sponsored listing placement (paid boost)
+- [ ] Reviews or ratings on listings (optional but common)
+- [ ] Map view (if location-relevant)
+- [ ] Listing owner dashboard (edit own listing, view basic stats)
+- [ ] SEO essentials: sitemap, meta tags per listing, canonical URLs
+- [ ] Reporting for admin: listing count by category, top searched terms
+
+## Data Model Starter
+
+| Entity | Key Fields | Relationships |
+|---|---|---|
+| Listing | name, slug, description, status (pending/approved/rejected), location, claimed_by | belongs to Category; has many Reviews; optionally belongs to Owner (User) |
+| Category | name, slug, parent_category_id | has many Listings; self-referencing for subcategories |
+| Owner (User) | name, email, role | has many Listings (claimed) |
+| Review | rating, body, author_name, listing_id | belongs to Listing |
+| Featured Placement | listing_id, start_date, end_date, price_paid | belongs to Listing |
+| Submission | raw submitted fields, status, submitted_at | converts into Listing upon approval |
+
+## Core User Flows
+
+1. Visitor searches/filters directory → views listing detail → contacts business or clicks through
+2. Business owner submits new listing → admin reviews → listing goes live
+3. Business owner claims existing unclaimed listing → verifies ownership → gains edit access
+4. Business owner pays to feature their listing → appears in top/sponsored slots
+5. Visitor leaves a review on a listing → review appears (moderated or instant)
+6. Admin browses moderation queue → approves/rejects pending listings and reviews
+
+## Monetization Pattern
+
+Primary: featured/sponsored listing fees (flat fee or recurring subscription for premium placement, badges, or extra photos/fields). Secondary: lead-gen fees (charge businesses per inquiry/click generated). Some directories charge a one-time or annual listing fee instead of free submissions, especially in B2B niches. Display ads are a weak fallback — avoid as primary model unless traffic is already very high.
+
+## Build Order (MVP fastest path)
+
+1. Listing + Category data model, seeded manually or via import script
+2. Listing detail page + category browse page (the SEO-indexable core)
+3. Search and filter UI
+4. Submit-a-listing form → goes into a pending/admin-approval state
+5. Basic admin moderation queue (approve/reject)
+6. Defer: claim flow, reviews, featured placement, map view, owner dashboard
+
+## Example AI Build Prompts
+
+```
+Build a directory listing data model in [Postgres/Supabase] with listings,
+categories (supporting nested subcategories via parent_category_id), and a
+status field (pending/approved/rejected) for moderation. Include a slug field
+generated from the listing name for SEO-friendly URLs.
+```
+
+```
+Build a directory browse page in [Next.js] with server-side rendering for SEO,
+showing listings filtered by category and a text search box, paginated 20 per
+page. Each listing card links to a detail page at /listings/[slug] with full
+structured data (schema.org LocalBusiness) embedded for search engines.
+```
+
+```
+Build a "submit your listing" public form that collects name, category,
+description, location, and contact info, saves it with status=pending, and
+sends an email notification to the admin. Build a simple admin moderation
+page listing all pending submissions with approve/reject buttons.
+```

package/templates/docs/product-types/INTERNAL_TOOL_TEMPLATE.md

@@ -0,0 +1,77 @@
+# Internal Tool Template
+
+Internal tools have a captive, forgiving-on-design but unforgiving-on-correctness user base — your coworkers will tolerate ugly UI but will not tolerate a tool that loses data, skips an approval step, or can't explain who did what. Plan around the existing company process you're replacing or augmenting (the paper form, the spreadsheet, the Slack thread) — the fastest path to adoption is matching that mental model, not redesigning the process from scratch. Build the audit log and permission model early; internal tools routinely get audited later for "who approved this" and you do not want that to be undiscoverable.
+
+## Feature Checklist
+
+- [ ] Internal auth (SSO/company login preferred over public signup)
+- [ ] Role-based permissions matching org structure (requester/approver/admin)
+- [ ] Core workflow/form (the specific process being digitized)
+- [ ] Approval flow with explicit states (submitted → approved/rejected → done)
+- [ ] Audit log: every state change recorded with actor, timestamp, before/after
+- [ ] Notifications to relevant people at each workflow step
+- [ ] Search/filter over historical records
+- [ ] Integration with existing systems (HR system, accounting, Slack, email)
+- [ ] Admin override/escalation path for stuck items
+- [ ] Reporting/export for compliance or management review
+- [ ] Bulk actions (approve multiple, reassign multiple) for power users
+- [ ] Comments/notes thread on each record for context
+- [ ] Configurable approval rules (e.g., amount-based routing) if process varies
+
+## Data Model Starter
+
+| Entity | Key Fields | Relationships |
+|---|---|---|
+| User | name, email, role, department, manager_id | has many Requests (as requester or approver) |
+| Request / Record | type, status, submitted_by, current_step, payload (JSON) | belongs to User (requester); has many Approvals, Comments |
+| Approval Step | request_id, approver_id, status, decided_at, comment | belongs to Request and User (approver) |
+| Audit Log Entry | actor_id, action, target_type, target_id, before, after, timestamp | belongs to User; references any entity |
+| Integration Sync Log | system_name, request_id, status, synced_at | belongs to Request |
+| Comment | body, author_id, request_id, created_at | belongs to Request and User |
+
+## Core User Flows
+
+1. Employee submits a request via form → enters approval queue
+2. Approver gets notified → reviews → approves or rejects with comment
+3. (If multi-step) request routes to next approver based on rules (e.g., amount threshold)
+4. Requester gets notified of final decision → record marked done/closed
+5. Admin searches historical requests → filters by status/date/department for review
+6. Admin exports records for compliance/audit purposes
+7. Stuck request escalated to admin → manually reassigned or force-resolved
+
+## Monetization Pattern
+
+No direct monetization — value is internal: hours saved vs. manual process (spreadsheet/email/paper), error reduction, and audit/compliance readiness. Justify build cost by estimating time currently spent per cycle of the manual process × frequency × number of people involved, and track that as the tool's "ROI metric" post-launch instead of revenue.
+
+## Build Order (MVP fastest path)
+
+1. Core request form + record model matching the existing process exactly
+2. Single-step approval (submit → approve/reject) before building multi-step routing
+3. Notifications for submission and decision (email is enough for MVP)
+4. Audit log capturing every status change
+5. Basic search/filter over records for admins
+6. Defer: multi-step routing rules, integrations with other internal systems, bulk actions
+
+## Example AI Build Prompts
+
+```
+Build a request/approval workflow data model in [Postgres/Supabase] with
+requests, approval_steps, and audit_log tables as described below, where every
+status change on a request automatically writes an audit_log entry with actor,
+before-state, after-state, and timestamp via a database trigger or application
+hook. [paste Data Model Starter table]
+```
+
+```
+Build an approval queue page in [React/Next.js] that shows the logged-in
+user's pending approvals (requests where they are the current approver),
+with approve/reject buttons that require a comment on reject, and update the
+request status and notify the requester immediately on decision.
+```
+
+```
+Build an audit log viewer page for admins showing every action taken on
+requests (submitted, approved, rejected, escalated) in a searchable, filterable
+table with columns for actor, action, target request, timestamp, and an
+expandable before/after diff for status or field changes.
+```

package/templates/docs/product-types/LEADGEN_TEMPLATE.md

@@ -0,0 +1,78 @@
+# Lead Generation Website Template
+
+A lead-gen site isn't a product you log into — it's a conversion machine where the "user" converts once (becomes a lead) and then exits to a sales or nurture process. Plan the *funnel*, not the app: traffic source → landing page → form → lead scoring → handoff/follow-up. The build is judged on conversion rate and lead quality, not feature richness. Build the form-to-CRM handoff before you polish design — a beautiful landing page that drops leads into a void is worse than a plain one that reliably notifies sales.
+
+## Feature Checklist
+
+- [ ] Landing page(s) with clear single CTA (one offer per page, no nav distractions)
+- [ ] Lead capture form (name, email, phone, qualifying questions)
+- [ ] Form validation + spam/bot protection (honeypot or captcha)
+- [ ] Thank-you page / confirmation step (with next-step instruction)
+- [ ] Lead storage (database or direct CRM push)
+- [ ] Lead scoring rules (basic: based on answers, source, or company size)
+- [ ] Email confirmation / autoresponder on submission
+- [ ] Follow-up sequence (drip emails, typically 3-7 touches)
+- [ ] CRM handoff/integration (webhook, Zapier, or native API push)
+- [ ] UTM/source tracking on every lead (know which campaign drove it)
+- [ ] A/B testing capability for headline/CTA/form length
+- [ ] Analytics: conversion rate by page/source, form abandonment tracking
+- [ ] Calendar booking integration (if next step is a sales call)
+- [ ] Admin view: list of leads with status (new/contacted/qualified/converted)
+
+## Data Model Starter
+
+| Entity | Key Fields | Relationships |
+|---|---|---|
+| Lead | name, email, phone, source, utm_campaign, status, score | belongs to Campaign; has many FollowUp events |
+| Campaign / Landing Page | slug, headline, offer, traffic_source | has many Leads |
+| Form Submission | raw form fields (JSON), submitted_at, ip_address | converts into Lead |
+| FollowUp Event | type (email/call/sms), sent_at, sequence_step | belongs to Lead |
+| Scoring Rule | field, condition, points | applied to Lead at submission time |
+| Integration Log | destination (CRM/webhook), payload, status, sent_at | belongs to Lead |
+
+## Core User Flows
+
+1. Visitor arrives from ad/search/social → lands on offer-specific page
+2. Visitor reads offer → fills lead capture form → submits
+3. System scores lead, tags source, pushes to CRM/webhook
+4. Visitor sees thank-you page → receives confirmation email immediately
+5. Lead enters follow-up sequence (automated emails over days/weeks)
+6. Sales/admin reviews lead list → marks contacted/qualified/converted
+7. (Optional) Lead books a call directly via embedded calendar on thank-you page
+
+## Monetization Pattern
+
+The site itself rarely charges money directly — it generates leads that get monetized downstream: (a) internal sales team closes them into a paid product/service, (b) leads are sold/transferred to a third party (lead-gen-as-a-business, common in insurance/legal/home-services niches), or (c) leads feed a SaaS/membership funnel where the real monetization happens after signup. Plan and report on cost-per-lead and lead-to-customer rate as the core economics, not direct site revenue.
+
+## Build Order (MVP fastest path)
+
+1. Single landing page with one offer and one form (no CMS, hardcode content)
+2. Form submission → store lead in database + send confirmation email
+3. UTM/source capture on form submission
+4. Simple admin list view of leads with status field
+5. One CRM/webhook integration (even a basic Zapier-style webhook push)
+6. Defer: lead scoring rules, multi-step follow-up sequences, A/B testing, calendar booking
+
+## Example AI Build Prompts
+
+```
+Build a lead capture landing page in [Next.js/HTML+Tailwind] with a single
+headline, 3 benefit bullets, a lead form (name, email, phone, one qualifying
+dropdown question), and a thank-you state shown inline after submit without
+a page reload. Include UTM parameter capture from the URL into hidden form fields.
+```
+
+```
+Build a lead intake API endpoint that accepts form submissions, validates
+input, calculates a lead score based on the qualifying answer (e.g.,
+budget > $5k = +30 points), stores the lead in the database with status=new,
+sends a confirmation email via [Resend/SendGrid], and pushes the lead payload
+to a configurable webhook URL for CRM handoff.
+```
+
+```
+Build an admin leads dashboard showing all captured leads in a table with
+columns for name, email, source/UTM campaign, score, status, and submitted
+date, sortable by score and date, with a status dropdown per row (new/contacted/
+qualified/converted) that updates inline without a page reload.
+```

package/templates/docs/product-types/MARKETPLACE_TEMPLATE.md

@@ -0,0 +1,81 @@
+# Two-Sided Marketplace Template
+
+A marketplace is the only product type where you must plan and build for two distinct users (supply and demand) who need each other to show up before either gets value — the classic cold-start problem. Plan liquidity strategy explicitly: which side do you seed manually first, and how do you fake density until real density exists (concierge onboarding, manually matched first transactions, seeded supply). Trust & safety (reviews, verification, dispute handling) is not a "nice to have later" feature here — it is the mechanism that lets strangers transact with each other, which is the entire point of the product. Build matching/discovery and a manual-first transaction flow before automating payments and escrow.
+
+## Feature Checklist
+
+- [ ] Supply-side profile/listing creation (the thing being offered: service, product, space)
+- [ ] Demand-side browse/search/discovery with filters
+- [ ] Matching logic (search ranking, recommendation, or request-based matching)
+- [ ] Messaging between supply and demand sides
+- [ ] Booking/transaction flow (request → accept/decline → confirm)
+- [ ] Payment processing with escrow or delayed payout to supply side
+- [ ] Take-rate fee calculation applied automatically on each transaction
+- [ ] Reviews/ratings (typically both directions — buyer rates seller and vice versa)
+- [ ] Identity/listing verification (badges, ID checks, or manual approval)
+- [ ] Dispute/resolution flow (cancellation, refund request, support escalation)
+- [ ] Availability/calendar management (if service or space-based)
+- [ ] Notifications for both sides at every transaction stage
+- [ ] Admin moderation tools (suspend users/listings, review disputes)
+- [ ] Supply-side payout dashboard (earnings, pending payouts, history)
+
+## Data Model Starter
+
+| Entity | Key Fields | Relationships |
+|---|---|---|
+| Supplier (User) | name, verification_status, payout_account | has many Listings; has many Transactions (as seller) |
+| Buyer (User) | name, payment_method | has many Transactions (as buyer); has many Reviews (written) |
+| Listing | title, price, category, availability, status | belongs to Supplier; has many Transactions, Reviews |
+| Transaction / Booking | listing_id, buyer_id, supplier_id, status, amount, fee_amount | belongs to Listing, Buyer, Supplier |
+| Review | rating, body, author_id, direction (buyer_to_seller/seller_to_buyer), transaction_id | belongs to Transaction |
+| Message | thread_id, sender_id, body, timestamp | belongs to Transaction or a pre-transaction inquiry thread |
+| Payout | supplier_id, amount, status, period | belongs to Supplier; aggregates multiple Transactions |
+
+## Core User Flows
+
+1. Supplier creates a listing → goes live after verification/moderation
+2. Buyer browses/searches → filters → views listing detail
+3. Buyer messages supplier or directly books/requests → supplier accepts/declines
+4. Buyer pays → funds held (escrow) → service/product delivered
+5. Funds released to supplier (minus take-rate fee) after completion/confirmation
+6. Both sides leave reviews → reviews appear on respective profiles
+7. Dispute raised (no-show, quality issue) → resolution flow → refund or payout decision
+
+## Monetization Pattern
+
+Take-rate (percentage or flat fee) on every transaction is the dominant model — typically 10-20% depending on category and whether the marketplace adds significant value (payment handling, trust, marketing) versus just listing. Variants: charge the take-rate to supply side, demand side, or split between both. Secondary revenue: featured/boosted listing placement (similar to directory monetization) and supplier subscription tiers for lower take-rate or extra visibility at volume.
+
+## Build Order (MVP fastest path)
+
+1. Listing model + supplier-side creation form (seed initial supply manually if needed)
+2. Buyer-side browse/search page (no fancy matching algorithm yet — simple filters)
+3. Manual or simple request-accept booking flow (skip real-time availability calendars at first)
+4. Payment processing with a basic hold/release mechanism (escrow-lite via manual admin release if true escrow is too complex for MVP)
+5. Take-rate fee calculation on each transaction
+6. Reviews (single direction is fine for MVP, add bidirectional later)
+7. Defer: messaging system, dispute automation, payout dashboards, identity verification, advanced matching
+
+## Example AI Build Prompts
+
+```
+Build a marketplace data model in [Postgres/Supabase] with suppliers, listings,
+buyers, and transactions, where every transaction stores both the gross amount
+and a calculated platform_fee (e.g., 15% of amount), and a net_payout field for
+what the supplier receives. Include a transaction status enum: requested,
+accepted, paid, completed, disputed, refunded.
+```
+
+```
+Build a booking request flow in [Next.js] where a buyer submits a request on
+a listing, the supplier receives a notification and can accept or decline
+within the app, and accepting transitions the transaction to a payment step
+using [Stripe Connect] with funds held until the buyer confirms completion.
+```
+
+```
+Build a bidirectional review system where after a transaction is marked
+completed, both the buyer and supplier are prompted to rate each other
+(1-5 stars + optional text), reviews are only published once both sides have
+submitted (or after a 14-day window), and each user's profile shows their
+average rating and review count.
+```

package/templates/docs/product-types/MEMBERSHIP_TEMPLATE.md

@@ -0,0 +1,80 @@
+# Membership / Subscription Content Site Template
+
+The thing that makes membership sites different from regular SaaS: the product *is* access and belonging, not a tool. Retention depends as much on perceived ongoing value (new content, community activity) as on features. Plan content cadence and tier structure before writing code — a membership site with great gating logic but no content pipeline behind it will churn in month two. Build billing and access-control first; content can be added continuously after launch, but a broken paywall kills trust immediately.
+
+## Feature Checklist
+
+- [ ] User signup/login with email verification
+- [ ] Subscription billing (recurring, via Stripe or similar)
+- [ ] Multiple membership tiers with different access levels
+- [ ] Content gating by tier (lock icon / paywall on restricted content)
+- [ ] Content library (courses, posts, videos, downloads) with categories
+- [ ] Progress tracking (for course-style content — completed/in-progress)
+- [ ] Member profile / account settings (update card, change plan, cancel)
+- [ ] Community space (comments, forum, or chat) — even basic threaded comments
+- [ ] Trial period or free tier for top-of-funnel conversion
+- [ ] Dunning/failed-payment handling (retry, grace period, downgrade)
+- [ ] Email notifications (new content drop, billing receipt, payment failed)
+- [ ] Admin panel: publish content, manage tiers, view member list
+- [ ] Cancellation flow (self-serve, with retention offer optional)
+- [ ] Search within gated content
+
+## Data Model Starter
+
+| Entity | Key Fields | Relationships |
+|---|---|---|
+| Member (User) | name, email, status (active/cancelled/past_due) | has one Subscription; has many Progress records, Comments |
+| Subscription | tier_id, status, current_period_end, stripe_customer_id | belongs to Member; belongs to Tier |
+| Tier | name, price, billing_interval, access_level | has many Subscriptions; gates Content |
+| Content | title, type (post/video/course/download), tier_required, published_at | belongs to Category; has many Progress records, Comments |
+| Category | name, order | has many Content |
+| Progress | content_id, member_id, status, completed_at | belongs to Member and Content |
+| Comment | body, member_id, content_id, created_at | belongs to Member and Content |
+
+## Core User Flows
+
+1. Visitor browses free/teaser content → hits paywall → signs up
+2. Choose tier → enter payment → instant access to gated content
+3. Member browses content library by category → consumes content → progress saved
+4. Member engages community (comment/discuss) on a piece of content
+5. Member upgrades/downgrades tier → access adjusts immediately
+6. Payment fails → grace period → member updates card or gets downgraded
+7. Member cancels → access continues until period end → then reverts to free/no access
+
+## Monetization Pattern
+
+Recurring subscription revenue, typically monthly and annual options (annual at a discount to improve cash flow and reduce churn). Tiering usually splits on content depth, community access, or live components (e.g., "Basic" content-only vs. "Pro" with community + live calls). A free or trial tier is the primary acquisition lever — most membership sites convert from free content, not cold ads, so plan a generous-but-bounded free layer.
+
+## Build Order (MVP fastest path)
+
+1. Auth (signup/login) + member account model
+2. Stripe subscription integration with one paid tier (skip multi-tier at first)
+3. Content model + manual admin publishing (no fancy CMS needed yet)
+4. Tier-based gating logic (show/hide or blur content based on access)
+5. Member dashboard showing accessible content
+6. Basic email notifications (welcome, receipt, payment failed)
+7. Defer: community/comments, progress tracking, multiple tiers, dunning automation
+
+## Example AI Build Prompts
+
+```
+Build a content-gating system in [Next.js/Supabase] where each Content row has
+a tier_required field, and the UI shows full content if the logged-in member's
+active subscription tier meets or exceeds tier_required, otherwise shows a
+blurred preview with an "Upgrade to unlock" CTA linking to the billing page.
+```
+
+```
+Set up Stripe subscription billing for a membership site with two tiers
+(Basic $19/mo, Pro $49/mo, both with annual options at 20% off). Implement
+webhook handlers for subscription.created, updated, and payment_failed that
+sync subscription status into our database, including a grace period of 5 days
+on failed payment before downgrading access.
+```
+
+```
+Build a member dashboard page that lists all content the member's tier grants
+access to, grouped by category, with a progress indicator (not started / in
+progress / completed) per item, and a "continue where you left off" section
+at the top showing the 3 most recently accessed items.
+```

package/templates/docs/product-types/SAAS_TEMPLATE.md

@@ -0,0 +1,79 @@
+# General SaaS Product Template
+
+Generic SaaS is the hardest type to template precisely because the "core workflow" is unique to your product — but the scaffolding around it (auth, billing, settings, multi-tenancy) is almost identical across every SaaS ever built. Plan the boring scaffolding fast and cheaply (most of it is now solvable with off-the-shelf tools/templates) so you can spend your real design effort on the one workflow that makes your product different. Decide your multi-tenancy model (single-user accounts vs. team/org accounts with multiple seats) before writing a single migration — retrofitting org-level data isolation later is one of the most expensive mistakes in SaaS.
+
+## Feature Checklist
+
+- [ ] Signup/login (email+password and/or OAuth)
+- [ ] Email verification and password reset
+- [ ] Organization/workspace model (if multi-user) with invite flow
+- [ ] Subscription billing (plans, trial, upgrade/downgrade, cancel)
+- [ ] Usage metering (if usage-based pricing) — track and enforce limits
+- [ ] The core workflow (the actual reason the product exists — define explicitly)
+- [ ] Settings: account, billing, team members, API keys/integrations
+- [ ] Role-based permissions within an organization (owner/admin/member)
+- [ ] Notifications (in-app and/or email) for key events
+- [ ] Onboarding flow (first-run experience guiding to first value)
+- [ ] Empty states for every list/dashboard (new accounts have no data yet)
+- [ ] Audit/activity log for account-level actions (helps support & trust)
+- [ ] API (if applicable) with documentation and key management
+- [ ] Data export / account deletion (for compliance and trust)
+
+## Data Model Starter
+
+| Entity | Key Fields | Relationships |
+|---|---|---|
+| Organization (Tenant) | name, plan_id, status, created_at | has many Users, Subscriptions, core-workflow entities |
+| User | name, email, role, organization_id | belongs to Organization; has many Sessions |
+| Subscription | plan_id, status, current_period_end, stripe_customer_id | belongs to Organization |
+| Plan | name, price, billing_interval, limits (JSON) | has many Subscriptions |
+| Invite | email, role, organization_id, status, token | belongs to Organization |
+| Core Workflow Entity | (product-specific — e.g., "Project," "Document," "Campaign") | belongs to Organization; owned/edited by Users |
+| Audit Log | actor_id, action, target, timestamp | belongs to Organization |
+
+## Core User Flows
+
+1. Visitor signs up → verifies email → lands in onboarding
+2. New user completes onboarding → reaches "aha moment" of core workflow
+3. User invites teammate → teammate joins organization with assigned role
+4. User starts free trial → uses core workflow → hits paywall or trial expiry
+5. User upgrades plan → billing processed → limits/features unlock
+6. Admin manages team (roles, removal) and billing in settings
+7. User integrates via API or third-party app (if applicable)
+
+## Monetization Pattern
+
+Recurring subscription, usually tiered by usage (seats, volume, feature access) or a hybrid of seat-based + usage overage. Freemium or free-trial is the dominant acquisition motion for self-serve SaaS; sales-assisted SaaS instead gates pricing behind a "Contact Us" for higher tiers. Annual billing at a discount improves cash flow and reduces churn — offer it from day one even with just one tier.
+
+## Build Order (MVP fastest path)
+
+1. Auth + single-tenant account model (add org/multi-user later if needed for MVP)
+2. The one core workflow that is the entire reason to use the product — nothing else
+3. Minimal settings (account info, password change)
+4. Stripe integration with one paid plan + trial (skip tiering complexity at first)
+5. Basic onboarding (a 2-3 step guided first action)
+6. Defer: team/org multi-user, roles/permissions, API, audit log, usage metering
+
+## Example AI Build Prompts
+
+```
+Build a multi-tenant SaaS data model in [Postgres/Supabase] with organizations,
+users (belonging to one organization with a role: owner/admin/member),
+subscriptions, and plans. Add row-level security so users can only ever query
+data scoped to their own organization_id.
+```
+
+```
+Build a self-serve onboarding flow in [Next.js] for a new signup: after email
+verification, walk the user through 3 steps (create first [core entity],
+invite a teammate (optional/skippable), see their first piece of real data)
+ending on the main app dashboard, with a progress indicator across all 3 steps.
+```
+
+```
+Integrate Stripe Billing with a 14-day free trial, one monthly/annual plan,
+and a customer portal link for self-serve plan management. Implement webhook
+handlers for checkout.session.completed, customer.subscription.updated, and
+customer.subscription.deleted that keep our organizations table's
+subscription_status field in sync.
+```