30 ChatGPT Prompts That Build SaaS Websites

You are a SaaS pricing designer who writes plan pages people can defend on a sales call. <context> Build a full SaaS pricing page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. This is a /pricing page with plans and seats, not a homepage and not a one-CTA landing page. </context> <inputs> - Product: [PRODUCT] - Three plans with prices: [PLANS AND PRICES] - Seats or included users per plan: [SEATS] - Hard limits per plan: [PROJECTS, VISITORS, STORAGE] - Plan to highlight: [RECOMMENDED PLAN] - Currency and tax note: [CURRENCY] - Proof I have: [QUOTE, LOGO, OR NONE] </inputs> <task> Build the page: sticky mini-nav back to Product, Features, Docs; a pricing hero that states who each plan is for; three plan cards with price, seats, limits, feature list, and CTA; a highlighted recommended plan; a feature comparison table under the cards; an FAQ (seats, unused seats, refunds, enterprise); and a custom or talk-to-sales band. Write honest limit copy. If a cell is unknown, write [VERIFY]. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Mobile-first, accessible contrast, semantic HTML, real benefit copy (no lorem ipsum). - Accessible table with headers. Cards stack on a phone. - Do not invent prices, seat counts, or unlimited claims I did not give. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then explain why you highlighted that plan and what to test first on the CTA labels. </format>

You are a SaaS monetization designer who explains per-seat pricing without a spreadsheet. <context> Build a per-seat SaaS pricing page as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Visitors should see price per seat, what a seat means, and a live total as they change seat count. </context> <inputs> - Product: [PRODUCT] - What a seat is: [EDITOR / VIEWER / GUEST RULES] - Price per seat: [AMOUNT AND CADENCE] - Volume breaks if any: [E.G. 1-10, 11-50] - Minimum seats: [MIN] - What is not a billable seat: [EXCLUSIONS] - Enterprise threshold: [SEAT COUNT OR [VERIFY]] </inputs> <task> Build the page: hero that defines a seat in one sentence; a seat stepper or slider that updates a monthly total with vanilla JS; a volume-break table if I gave breaks; a who needs a seat / who does not section; a simple plan card plus an enterprise band; FAQ on unused seats, offboarding, and viewers; and a CTA to start with [MIN] seats. Compute the sample total from constants I can edit. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Seat math must stay consistent. Do not invent volume breaks. - Accessible slider or number input with a visible total. - Mobile-first, semantic HTML, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then show the seat-total formula and where to paste real prices. </format>

You are a usage-based pricing writer who makes meters understandable on one page. <context> Build a usage-based SaaS pricing page as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. The meter is [METER]. People should estimate a bill before they talk to sales. </context> <inputs> - Product: [PRODUCT] - Meter name and unit: [METER] - Included units per plan if any: [INCLUDED] - Price per unit after that: [UNIT PRICE] - Worked example volume: [EXAMPLE VOLUME] - Overage or hard cap: [OVERAGE RULE] - What does not count as usage: [EXCLUSIONS] </inputs> <task> Build the page: hero that names [METER] and the unit price; a calculator that multiplies example volume times unit price (vanilla JS, labeled constants); three example bills (small, mid, busy); a what counts / what does not list; a plans band if I gave included units; an overage honesty block; FAQ; and a CTA. If I did not give a number, mark [VERIFY] instead of guessing. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Calculator math must match the constants. No hidden fees in the copy unless I listed them. - Mobile-first, accessible form controls, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then explain the bill formula and which example a first-time buyer should start on. </format>

You are a SaaS pricing designer who writes monthly / annual toggles without fake discounts. <context> Build a SaaS pricing page with a billing-period toggle as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Prices must switch in place. Savings appear only from the numbers I give. </context> <inputs> - Product: [PRODUCT] - Plans with monthly and annual prices: [PLANS] - Seats included per plan: [SEATS] - Recommended plan: [PLAN] - How annual is billed: [PREPAY YEAR / MONTHLY AT ANNUAL RATE] - Savings I can claim: [PERCENT OR DOLLAR, OR [VERIFY]] </inputs> <task> Build the page: pricing hero; an accessible monthly / annual toggle that updates every card price and the savings line; three plan cards with seats and CTAs; a comparison table whose price row updates with the toggle; FAQ on proration, refunds, and unused seats; and a closing CTA. Store prices in labeled JS constants. Compute savings from those constants, never a hardcoded 20 percent. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Toggle is a button pair or switch with aria-pressed. Keyboard operable. - Do not invent an annual discount I did not give. - Mobile-first, semantic HTML, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then show the savings math and what to test on the default period. </format>

You are a packaging strategist who puts core plans, seat packs, and add-ons on one honest page. <context> Build a SaaS pricing page that stacks a base plan with optional seat packs and paid add-ons, as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. </context> <inputs> - Product: [PRODUCT] - Core plans: [PLANS AND PRICES] - Seat pack: [E.G. +5 SEATS FOR $X] - Paid add-ons: [SSO, AUDIT LOG, PREMIUM SUPPORT, OR LIST] - What is included in core: [INCLUDED] - Who should skip add-ons: [SKIP RULE] </inputs> <task> Build the page: hero that says plans plus optional packs; core plan cards; a seat-pack band with the pack math; an add-ons grid with price, who it is for, and who should skip it; a sample stack (Team + 10 seats + SSO) using only numbers I gave or [VERIFY]; FAQ; and CTAs per plan. Keep add-on cadence aligned with the plan cadence I stated. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Do not invent add-on prices. Mark gaps as [VERIFY]. - Mobile-first, accessible cards and table, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which add-on should sit next to checkout versus a talk-to-sales path. </format>

You are a product marketer who writes SaaS feature overviews grouped by jobs, not menus. <context> Build a SaaS /features overview as one self-contained HTML file with inline CSS and sticky nav, returned as a working page I can open in the chat. This is a marketing features index, not a docs site and not a homepage clone. </context> <inputs> - Product: [PRODUCT] - Jobs the product does: [4-6 JOBS] - Two or three capabilities under each job: [LIST OR INVENT REALISTIC NAMES] - Plan gates if any: [FREE / PRO / ENTERPRISE] - Proof I have: [QUOTES, METRICS] - Vibe: [CLEAN / TECHNICAL / WARM] </inputs> <task> Build the page: sticky nav (Product, Features, Pricing, Docs, Changelog); a features hero; job-grouped sections with capability cards, a one-line outcome, and a screenshot placeholder; plan-gate badges only where I named a gate; a jump links row; a CTA to start or see pricing; and a short 'not in v1' honesty line if I listed gaps. Write benefit copy per card. Link a few cards to /features/[slug] style hrefs. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Mobile-first, accessible contrast, semantic HTML, real benefit copy (no lorem ipsum). - Do not dump 40 icons. Six jobs is a ceiling. - Do not invent plan gates or proof. Mark gaps as [VERIFY]. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list the job groups and which card should become a deep-dive page first. </format>

You are a product marketer who sells one SaaS capability on its own URL. <context> Build a single-feature marketing page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. Stay on [FEATURE]. This is a /features/[feature] page on a SaaS site, not a full product tour and not a landing page with no nav. </context> <inputs> - Product: [PRODUCT] - Feature: [FEATURE] - Job it finishes: [OUTCOME] - Old way: [PAINFUL OLD WAY] - Which plans include it: [PLANS] - Proof I have: [QUOTE, METRIC, SCREENSHOT IDEA] </inputs> <task> Build the page: slim product nav; hero that names [FEATURE] and [OUTCOME]; before versus after; how it works in three captioned steps with screenshot placeholders; who it is for; plan availability note; one feature-specific testimonial or [VERIFY]; a related features strip; and a CTA that matches the plan (start trial or talk to sales). Write copy only about this capability. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Mobile-first, accessible contrast, semantic HTML, real benefit copy (no lorem ipsum). - Do not expand into a homepage. Do not invent plan availability. - Styled placeholders labeled for each screenshot. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say where a 20-second clip would help more than another paragraph. </format>

You are a platform marketer who writes SaaS integration directories buyers can scan. <context> Build a SaaS integrations catalog as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. It should feel like /integrations on a real SaaS site: featured tile, filters, cards, not a blog post. </context> <inputs> - Product: [PRODUCT] - Featured integration: [FIRST INTEGRATION] - Other integrations: [8-16 NAMES OR INVENT REALISTIC ONES] - Filter groups: [E.G. CRM, CHAT, BILLING, ANALYTICS] - What an integration usually does: [SYNC, ALERT, EMBED] - Build-your-own note: [API / WEBHOOKS / ZAPIER] </inputs> <task> Build the page: product nav; hero plus search-feel input that filters cards with vanilla JS; a featured [FIRST INTEGRATION] band with outcome copy and a Connect CTA; a card grid (logo placeholder, name, category, one-line job); filter chips; an API / webhooks band; and a request-an-integration note. Seed card data in a labeled JS array. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Filtering must work. Empty state if a chip has no cards. - Do not invent partner certifications. Mark official versus community as [VERIFY] if unknown. - Mobile-first, accessible chips and cards, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then explain how to add a real integration object to the array. </format>

You are a trust-center writer who builds SaaS security pages that survive a security questionnaire. <context> Build a SaaS security and compliance page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. Honest scope only. This is a /security page on the marketing site, not a legal policy dump. </context> <inputs> - Product: [PRODUCT] - Controls I have: [SSO, ROLES, AUDIT LOG, ENCRYPTION] - Certificates or audits I can name: [CERT] - Hosting region notes: [REGION OR [VERIFY]] - Who to contact for a questionnaire: [SECURITY EMAIL OR FORM] - What I do not claim yet: [OFF-LIMITS] </inputs> <task> Build the page: product nav; a calm hero; a controls grid (SSO, roles, seats vs access, audit log) using only [CONTROLS I HAVE]; a compliance band that names [CERT] or shows a [VERIFY] slot; a data-handling section; a subprocessors or hosting note; a request-SOC-report or questionnaire CTA; and FAQ. Write precise copy. Never imply a cert I put in [OFF-LIMITS]. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Mobile-first, accessible contrast, semantic HTML, no lorem ipsum. - Do not invent SOC 2, ISO, HIPAA, or pentest dates. - Mark unknown facts as [VERIFY]. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list every claim a reviewer will ask to see evidence for. </format>

You are a SaaS product marketer who maps features to roles buyers recognize. <context> Build a role-based SaaS features page as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. Visitors should switch [ROLE] and see the jobs that role gets, including seat implications. </context> <inputs> - Product: [PRODUCT] - Roles: [E.G. OWNER, ADMIN, MEMBER, VIEWER] - Default role to show: [ROLE] - Jobs per role: [LIST OR INVENT REALISTIC ONES] - Which roles burn a paid seat: [SEAT RULES] - Plan notes: [WHICH PLANS GET WHICH ROLE] </inputs> <task> Build the page: product nav; hero; role tabs or chips that filter the job cards with vanilla JS; each card shows the job, the capability, and whether it needs a paid seat; a seat-rules callout; a compare-roles table; and a CTA. Seed role and job data in labeled JS. Do not invent seat rules I did not give. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Role switch updates the grid without a reload. - Mobile-first, accessible tabs, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then explain the seat rule in one sentence and how to add a fourth role. </format>

You are a docs writer who ships a lite getting-started page for a SaaS marketing site. <context> Build a docs-lite getting-started page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. This is /docs or /start on a SaaS site: enough to do the first job, not a full documentation portal. </context> <inputs> - Product: [PRODUCT] - First value in one line: [FIRST VALUE] - Prerequisites: [ACCOUNT, STACK, PERMISSION] - Steps I know: [3-6 STEPS OR OUTLINE] - Where full docs will live later: [URL OR /DOCS] - Support path: [EMAIL, CHAT, COMMUNITY] </inputs> <task> Build the page: slim docs header (Start, Guides, API, Changelog); a short intro; numbered steps to [FIRST VALUE] with copy-ready commands or UI clicks; a prerequisite box; a common-error callout; next-step cards (invite a seat, read changelog, see pricing); and a still stuck link. Keep the page scannable. Use a left or top mini-toc with anchors. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Mobile-first, accessible contrast, semantic HTML, real instructional copy (no lorem ipsum). - Do not invent CLI flags or API routes I did not give. Mark them [VERIFY]. - This is lite. No 40-page sidebar. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list which step will break first if my UI labels differ. </format>

You are an onboarding writer who turns one SaaS job into a five-step docs-lite walkthrough. <context> Build a docs-lite walkthrough as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. The only job is [JOB TO BE DONE] inside [PRODUCT]. Not a feature catalog. </context> <inputs> - Product: [PRODUCT] - Job to be done: [JOB TO BE DONE] - Finished output they can see: [OUTPUT] - Who does this job: [ROLE] - Screens they will click: [SCREEN NAMES OR [VERIFY]] - Time it should take: [MINUTES] </inputs> <task> Build the page: docs-lite chrome; a goal line (In about [MINUTES] you will have [OUTPUT]); five numbered steps with UI copy, a screenshot placeholder, and a check-you-are-done line; a if this failed box; a you are done band; and next jobs (invite seats, look at changelog). Write like a patient teammate. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Exactly one job. No side quests in the main steps. - Do not invent UI labels. Use mine or [VERIFY]. - Mobile-first, semantic HTML, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which step needs a real screenshot first. </format>

You are an API docs writer who keeps a SaaS quickstart to one authenticated call. <context> Build an API quickstart docs-lite page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. One auth method. One happy-path request. One sample response. Not a full OpenAPI site. </context> <inputs> - Product: [PRODUCT] - Base URL: [BASE URL OR [VERIFY]] - Auth: [BEARER / API KEY HEADER / OTHER] - The one call: [METHOD AND PATH] - Sample JSON I can show: [BODY OR [VERIFY]] - Language for the sample: [CURL / JS FETCH] - Rate limit note: [NOTE OR [VERIFY]] </inputs> <task> Build the page: docs-lite nav (Start, API, Changelog); get an API key; authenticate; copy-ready [CURL / JS FETCH] for [METHOD AND PATH]; a sample 200 response block; two error codes with what to do; a rate-limit line; and next (webhooks, SDKs, changelog). Use placeholders like YOUR_API_KEY, never a real-looking secret. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Do not invent endpoints I did not give. Mark them [VERIFY]. - Code blocks must be selectable. Accessible headings. - Mobile-first, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list every [VERIFY] a real engineer must replace before this goes live. </format>

You are a SaaS admin-docs writer who covers seats, roles, and SSO on one lite page. <context> Build an admin setup docs-lite page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. Aimed at the person who owns billing and access, not the end user. </context> <inputs> - Product: [PRODUCT] - Seat model: [EDITORS BILLABLE, VIEWERS FREE, OR DESCRIBE] - Roles: [OWNER, ADMIN, MEMBER] - SSO availability: [PLAN AND PROTOCOL, OR [VERIFY]] - Domain capture or SCIM: [YES / NO / [VERIFY]] - Billing owner tasks: [INVOICES, SEAT PACKS] </inputs> <task> Build the page: docs-lite chrome; a 30-minute admin path (create workspace, invite seats, set roles, optional SSO); a seats and roles table; an SSO section that only claims what I gave; a before you turn on SSO warning (lockout, break-glass owner); a billing checklist; and a link to security or pricing. Write cautious, specific steps. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Do not invent SAML field names or IdP setup I did not give. - Mobile-first, accessible tables, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list the two admin mistakes this page should prevent. </format>

You are a support-content designer who builds a lite SaaS help-center home. <context> Build a help-center home as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. It is docs-lite: topic cards and a client-side search over a small article list, not Zendesk. </context> <inputs> - Product: [PRODUCT] - Topic groups: [GETTING STARTED, BILLING AND SEATS, FEATURES, ACCOUNT] - Article titles: [10-16 OR INVENT REALISTIC ONES] - Top tickets: [3 REAL QUESTIONS] - Contact path: [EMAIL / CHAT HOURS] </inputs> <task> Build the page: help header with a search input that filters article links via vanilla JS; a still stuck band that answers [TOP TICKETS] in one line each; topic cards; an article list grouped by topic; a billing and seats card that is hard to miss; and a contact footer. Seed articles in a labeled JS array. Search matches title text. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Search must work on the seeded titles. Empty state for no hits. - Mobile-first, accessible search, no lorem ipsum. - Do not pretend live chat exists unless I said so. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then explain how to add one real article object to the array. </format>

You are a product ops writer who keeps a public SaaS changelog people actually skim. <context> Build a dated product changelog as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. This is /changelog on a SaaS marketing site: dated entries, tags, not a blog and not a homepage. </context> <inputs> - Product: [PRODUCT] - Entries I have: [3-8 SHIPS WITH DATE, TAG, SUMMARY] - Tags to use: [NEW, IMPROVED, FIXED] - If I am short on entries: [INVENT 4 REALISTIC SAMPLE SHIPS LABELED SAMPLE] - RSS or subscribe note: [EMAIL OR NONE] - Timezone for dates: [TZ] </inputs> <task> Build the page: product nav plus Changelog in the current state; a short intro; a reverse-chronological list with date, tag pills, title, and 2-4 lines each; a skip to latest; a subscribe band only if I asked; and a footer link to docs-lite. If you invent samples, mark each card SAMPLE so I can swap them. Use ISO-like dates such as 2026-09-02, not vague last month. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Mobile-first, accessible contrast, semantic HTML, real release copy (no lorem ipsum). - Do not invent customer names or uptime percentages. - Tag color must stay consistent and readable. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list which sample entries to replace first and the entry HTML shape. </format>

You are a release-notes writer who documents one SaaS version like an engineer would. <context> Build a versioned release-notes page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. Center on [VERSION] for [PRODUCT], with a path back to the full changelog. </context> <inputs> - Product: [PRODUCT] - Version: [VERSION] - Ship date: [DATE] - Added / improved / fixed: [BULLETS] - Breaking changes: [LIST OR NONE] - Who must act: [ADMINS, API USERS, EVERYONE] - Rollback or support note: [NOTE OR [VERIFY]] </inputs> <task> Build the page: changelog-style header with [VERSION] and date; a who should read this strip; a breaking-changes banner if I listed any (or a none this time line); grouped notes; upgrade steps; a rollback or contact line; and prev / next version hrefs. Write in short, testable sentences. Mark unknown API paths as [VERIFY]. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Breaking changes cannot sit below a fold of cheerleading. - Mobile-first, semantic HTML, no lorem ipsum. - Do not invent versions I did not name. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which sentence an admin will forward to their team. </format>

You are a product marketer who writes a monthly whats-new recap for SaaS customers. <context> Build a monthly whats-new page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. It recaps [MONTH] for [PRODUCT] by theme, then links into the dated changelog. </context> <inputs> - Product: [PRODUCT] - Month: [MONTH] - Themes or ships: [3-6 THEMES WITH A LINE EACH] - Plan that got the work: [ALL / PRO / ENTERPRISE] - One feature to lead with: [LEAD FEATURE] - Link to full changelog: [/CHANGELOG] </inputs> <task> Build the page: a magazine-like recap hero for [MONTH]; a lead story on [LEAD FEATURE]; theme sections with a short why it matters and a changelog-style bullet; a plan badge where work is gated; a see every ship link; and a CTA to try the lead feature. Keep it skimmable. No fake launch-party tone. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Do not invent ships I did not list. If thin, say so and use [VERIFY] slots. - Mobile-first, semantic HTML, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then recommend the one theme to email, not the whole recap. </format>

You are a launch writer who turns one SaaS ship into a changelog-style launch page. <context> Build a feature-launch page that can live at /changelog/[feature] as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. It is a long changelog entry, not a sales landing page with no product nav. </context> <inputs> - Product: [PRODUCT] - Feature: [FEATURE] - Who has it: [ALL, PRO, ENTERPRISE, BETA] - How to turn it on: [DEFAULT ON / FLAG / ADMIN SETTING] - What it replaces: [OLD WORKFLOW] - Limits: [SEATS, VOLUME, OR NONE] - Docs-lite link: [/DOCS OR [VERIFY]] </inputs> <task> Build the page: product plus changelog nav; launch hero with date and eligibility; what changed; how to turn it on; a short how-to; limits and plan note; a known-issues line or [VERIFY]; links to docs-lite and pricing; and a back to changelog link. Write as a ship note, not a billboard. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Eligibility and plan sit high. Do not hide them in a footer. - Mobile-first, semantic HTML, no lorem ipsum. - Do not invent waitlist counts. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list the two support questions this page should kill. </format>

You are a product ops designer who makes a public changelog filterable without a CMS. <context> Build a filterable SaaS changelog as one self-contained HTML file with inline CSS and vanilla JS, returned as a working page I can open in the chat. [AUDIENCE] should hide entries that are not for them. </context> <inputs> - Product: [PRODUCT] - Audience default: [AUDIENCE] - Filters: [E.G. API, ADMIN, BILLING, APP] - Sample entries: [8-12 OR INVENT REALISTIC ONES LABELED SAMPLE] - Tags: [NEW, IMPROVED, FIXED] </inputs> <task> Build the page: changelog header; filter chips that show and hide entries with vanilla JS; a default chip for [AUDIENCE]; dated entries with audience + type tags; a count of visible entries; an empty state; and a note that this is the public log, not the status page. Seed entries in a labeled JS array with date, title, tags, audience, and body. </task> <constraints> - One self-contained, responsive HTML file; Google Fonts only plus vanilla JS. - Filters must work together in a simple AND or OR you document in a comment. - Mobile-first, accessible chips, no lorem ipsum. - Sample entries labeled so I can swap them. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then explain the filter logic and the entry object shape. </format>

You are a competitive-positioning writer who builds fair SaaS versus pages. <context> Build a [PRODUCT] versus [COMPETITOR] compare page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. This is a /compare/[competitor] marketing page with nav back to pricing and features, not a single-CTA landing page. </context> <inputs> - My product: [PRODUCT] - Competitor: [COMPETITOR] - Why people switch: [3-4 REAL DIFFERENTIATORS] - Honest concession: [ONE THING THEY DO WELL] - Seats and plans I can compare: [MY PLANS VS THEIRS, OR [VERIFY]] - Proof I have: [SWITCHER QUOTE, METRIC] - Primary CTA: [START FREE / SEE PRICING / BOOK DEMO] </inputs> <task> Build the page: product nav; hero that states the comparison and the one reason to switch; an accessible comparison table (seats, plans, SSO, support, limits) with honest cells; a why teams switch section; the concession band; a migration reassurance; FAQ; and a closing CTA. Do not invent their prices. Use [VERIFY] when I did not give a cell. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Confident, not petty. Include the concession. - Table has headers and stays scannable on a phone. - Mobile-first, semantic HTML, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which differentiator should lead the hero. </format>

You are a category-design writer who positions a SaaS product as the alternative to an old stack. <context> Build a category alternative page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. [PRODUCT] versus [CATEGORY] tools, for people already shopping a switch, with site nav still present. </context> <inputs> - Product: [PRODUCT] - Old category: [CATEGORY] - Jobs the old category fakes: [JOBS] - Who should stay on the old tools: [STAY] - Seats or pricing contrast I can make: [CONTRAST OR [VERIFY]] - Proof I have: [QUOTES, MIGRATION NOTES] </inputs> <task> Build the page: product nav; hero that names [CATEGORY] and the job [PRODUCT] actually finishes; a table of old-way versus new-way on 5 jobs; who should not switch; a seats or pricing contrast only if I gave numbers; a short migrate path; FAQ; and a switch CTA. Write for skeptics, not fans. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Do not smear a named vendor unless I named them. - Do not invent category-average prices. - Mobile-first, accessible table, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then name the search phrase this page should rank for. </format>

You are a SaaS packaging writer who builds an internal plan-versus-plan matrix buyers can scan. <context> Build a Free versus Pro versus Enterprise comparison page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. This is /compare/plans on a SaaS site, sibling to /pricing, not a homepage. </context> <inputs> - Product: [PRODUCT] - Plans: [FREE, PRO, ENTERPRISE OR MY NAMES] - Seats per plan: [SEATS] - Rows I care about: [SSO, SUPPORT, API, AUDIT LOG, LIMITS] - Recommended plan: [PLAN] - Prices if I have them: [PRICES OR POINT TO /PRICING] </inputs> <task> Build the page: product nav; a short hero; an accessible matrix with plans as columns and capabilities as rows, seats near the top; check, dash, or a short limit (not a vague yes); a recommended-column highlight; CTA under each plan; a when to pick each plan band; and FAQ on unused seats and upgrades. If a cell is unknown, write [VERIFY]. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Table must scroll or stack on a phone without losing headers. - Do not invent unlimited rows. Do not invent prices I did not give. - Mobile-first, semantic HTML, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then say which row will drive the most upgrades and which cell I must verify before publish. </format>

You are a migration marketer who writes switch-from pages that set honest import expectations. <context> Build a switch-from-[COMPETITOR] page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. People already using [COMPETITOR] should see a checklist, what imports, and what they will redo by hand. </context> <inputs> - Product: [PRODUCT] - Competitor they leave: [COMPETITOR] - What I can import: [OBJECTS OR CSV] - What they redo by hand: [MANUAL] - Time I can stand behind: [WINDOW OR [VERIFY]] - Seats mapping: [HOW SEATS TRANSLATE] - Help I offer: [CONCIERGE, DOCS, OFFICE HOURS] </inputs> <task> Build the page: product nav; hero for people leaving [COMPETITOR]; a 5-step switch checklist; an import versus redo table; a seats mapping note; a timeline that only uses [WINDOW] or [VERIFY]; a concierge or DIY path; FAQ; and a start migration or book help CTA. Be specific and calm. No dunking on [COMPETITOR]. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Do not invent importers or one-click claims. - Mobile-first, accessible checklist and table, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list the two sentences most likely to create a support ticket if they are wrong. </format>

You are a competitive analyst who builds a three-column SaaS feature matrix without fake scores. <context> Build a [PRODUCT] versus [RIVAL A] versus [RIVAL B] matrix page as one self-contained HTML file with inline CSS, returned as a working page I can open in the chat. Fair cells. Site nav stays. Not a takedown landing page. </context> <inputs> - Product: [PRODUCT] - Rival A: [RIVAL A] - Rival B: [RIVAL B] - Rows I can defend: [8-12 CAPABILITIES INCLUDING SEATS, PLANS, SSO] - Cells I know: [YES / NO / LIMIT, OR [VERIFY]] - Who each tool is for: [ONE LINE EACH] - Primary CTA: [SEE PRICING / START FREE / BOOK DEMO] </inputs> <task> Build the page: product nav; hero that names all three products; a who each is for strip; an accessible 3-column matrix with seats and plans near the top; [VERIFY] in any cell I did not confirm; a short reading guide (when to pick us, when to pick A, when to pick B); FAQ; links to single-rival vs pages; and a CTA. No invented 9.4 out of 10 scores. </task> <constraints> - One self-contained, responsive HTML file; no dependencies except Google Fonts. - Do not invent rival prices, certifications, or seat rules. - Table stays usable on a phone (scroll with sticky first column if needed). - Mobile-first, semantic HTML, no lorem ipsum. </constraints> <format> Return the full HTML as a working page you can open in the chat. If Canvas is available, put the file there. Then list every [VERIFY] cell I must fill before this page can rank without getting a lawyer email. </format>