CodeWisp ships as a YC W26 consumer creation platform with legal/policy pages but effectively no developer or support documentation surface: the only "help" the footer offers (FAQ, Update logs, About credits) is partially broken, contradicts itself across pages, or invisible to non-JS clients.
1. /pricing and /credits disagree about which paid plans exist (critical)
Problem: The pricing page lists four tiers: Free, Creator (20,000 credits/mo, $15), Pro (50,000 credits/mo, $29), and Enterprise (custom). The credits page lists a completely different set of four paid tiers: Creator (20,000), Pro (50,000), Legend (95,000), and Max (200,000) — with no mention of Enterprise. Legend and Max do not appear on the pricing page at all; Enterprise does not appear on the credits page at all.
Consequence: A prospective customer comparing plans gets two different answers about what they can buy. Anyone budgeting against the 95K/200K Legend/Max tiers shown on /credits cannot actually purchase them from /pricing, and anyone reading /credits has no way to discover the Enterprise option or its sales contact (fuelvin@codewisp.ai). Either the credits page is selling vaporware or the pricing page is hiding two tiers.
The fix: Pick one canonical plan list and render both pages from the same source. If Legend/Max are real tiers, add their prices and feature deltas to /pricing; if they are not, remove them from /credits.
2. The two revenue pages are missing from sitemap.xml entirely (critical)
Problem: sitemap.xml declares only 8 URLs: /, /courses, /explore, /sign-up, /sign-in, /terms, /privacy, /faq. Neither /pricing nor /credits — the two live pages whose mutually contradictory plan rosters are this audit's headline issue — is declared. Also missing: /blog, /create, /discuss, /mobile-app, /referral, /privacy-choices, , .
Code verification
Runtime snippet checks
Run the public examples from this audit in an isolated sandbox and attach the pass, fixed, skipped, and failed counts to the report.
Consequence: The two pages that close the sale on a paid subscription are explicitly excluded from CodeWisp's own discoverability manifest. Search-engine crawlers and AI agents that lean on sitemap.xml to rank or summarize what a site sells get a manifest in which the product's most commercial pages do not appear. Combined with finding 1, neither sitemap-driven crawler nor a user comparing the two visible pricing surfaces gets a coherent picture of what is for sale.
The fix: Add /pricing, /credits, /blog, /create, /discuss, and /mobile-app to sitemap.xml with appropriate priorities. Either generate sitemap.xml from the routing table or add a CI check that fails on undeclared public pages.
3. Footer-advertised "Update logs" page does not exist (significant)
Location: Footer Resources column on every page (homepage, /terms, /privacy, /mobile-app, etc.); link target /update-logs
Problem: Every page footer lists "Update logs" under Resources. On /terms it is rendered as plain text rather than a hyperlink. /update-logs, /updates, and /changelog all return HTTP 404.
Consequence: Users and AI agents looking for a changelog — the standard way to verify what the platform can currently do, what just shipped, and whether a bug they hit has been fixed — find a dead reference advertised in the footer of every page. For an AI-product where model behavior and credit costs vary by release, the absence of any public release history is a trust problem.
The fix: Either publish a real /update-logs page (even a static markdown list of dated entries) and hyperlink the footer item, or remove the "Update logs" entry from the footer entirely until the page exists.
4. No llms.txt, no llms-full.txt, no /docs surface, no API spec (significant)
Problem: There is no llms.txt or llms-full.txt. There is no /docs route. robots.txt blocks /api/ entirely (only /api/og/ is allowed), and no OpenAPI/JSON-schema spec is published anywhere. The only "machine-readable" surface is an 8-URL sitemap.xml that points exclusively at the homepage, /courses, /explore, sign-in/up, /terms, /privacy, and /faq.
Consequence: AI coding agents (Claude Code, Cursor, Copilot) and search-engine summarizers have nothing structured to index — they cannot tell an agent what credits cost per action, what models exist, what the credit free-tier rules are, or how the editor is invoked. A product whose entire pitch is "AI-assisted creation" is itself unreadable to AI clients.
The fix: Publish an llms.txt that points to the canonical pricing, credits, FAQ, and terms pages, plus an llms-full.txt snapshot of those pages' prose. If there is no public API, say so explicitly in /docs rather than 404'ing.
5. /faq is the only support surface and ships zero answer text to non-JS clients (significant)
Problem: The FAQ is the only page in the footer Resources column that resolves, and it appears in sitemap.xml at priority 0.6. The server-rendered HTML contains only "Loading…" and the eight question titles ("What is CodeWisp?", "Do I need to know how to code?", "How does it work?", etc.). The answer text is not present in the initial response and is presumably hydrated client-side.
Consequence: Search-engine indexers' text fallback, AI agents fetching the page, and any user on a JS-disabled or slow connection see questions with no answers. Because /faq is the only help surface CodeWisp publishes — there is no /help, /docs, /support, or /about — the company's entire public help text is invisible to crawlers.
The fix: Server-render the FAQ answers (Next.js getStaticProps or equivalent) so the prose ships in the initial HTML. The questions are static — there is no reason for them to be client-fetched.
6. Three different names for the legal agreement on the consent surface (critical)
Location: /sign-up acceptance text vs /terms body vs site footer
Problem: The sign-up page reads: "By signing up, you agree to our Terms of Use and Privacy Policy. If you're under 18, you agree your parent/guardian permits you to create this account and agrees to our Terms of Use." The legal document itself is titled "Terms of Service" throughout its own body. The footer lists it as simply "Terms." Three labels, one document.
Consequence: A user agreeing at sign-up technically agrees to "Terms of Use," a document that does not exist by that title anywhere on the site. The agreement contains binding individual arbitration via JAMS and a class-action waiver (section 15) and a USD $100 / 12-month liability cap (section 11). When a user later contests enforcement, the mismatch between "Terms of Use" at consent and "Terms of Service" in the actual document is a real consent-validity hazard for the highest-stakes clauses in the contract.
The fix: Pick one name — "Terms of Service" matches the document — and use it on the sign-up page, footer, and link text everywhere. Update parent/guardian consent text in the same pass.
7. /courses is sitemap priority 0.9 but unreachable from the site (significant)
Problem: /courses is the second-highest-priority page declared in sitemap.xml (0.9, behind only the homepage's 1.0) and contains a live "Introduction to Coding" course plus three "Coming soon" tracks. The page is not linked from the primary navigation (Explore, Discuss, Create, App, Community) or the footer. The only way to discover it is by reading sitemap.xml.
Consequence: A whole product surface — explicitly an "Introduction to Coding" curriculum from the founder, who the YC page claims has 22M+ YouTube subscribers — is invisible to real users. New creators with no coding background (i.e., exactly the persona the product targets) cannot find the introductory course unless they were told it exists.
The fix: Add "Courses" to the primary nav or the footer Resources column. If /courses is not yet ready for general traffic, drop its sitemap priority and add a noindex so it stops being the most-promoted page after the homepage.
8. Footer's /referral and /me redirect to sign-in with zero public description (significant)
Location: /referral and /me (linked from the footer as "Referral Program" and "My games")
Problem: Both pages are gated behind login — fetching either returns the "Sign in to continue building amazing games" page. There is no public landing copy explaining what the referral program rewards, what credits or revenue share it offers, or what "My games" contains.
Consequence: A potential new signup looking at the footer's "Referral Program" link to decide whether the program is worth participating in is forced to create an account first to discover the terms. For a referral program specifically, the marketing surface should be public — gating the description defeats the program.
The fix: Add a public /referral landing page that documents reward amounts, eligibility, and terms before requiring login. Either gate /me without showing it in the footer to logged-out users, or give it a public preview state.
9. "App" primary-nav link points to a waitlist, not an app (significant)
Problem: The primary navigation prominently exposes "App" as a top-level item alongside Explore, Discuss, and Create. The link resolves to /mobile-app, which says "Coming Soon — CodeWisp Mobile App… We're putting the finishing touches on it" with an email-capture form. No release window is given.
Consequence: A user clicking what looks like the gateway to "the CodeWisp app" instead gets a marketing waitlist. This is doubly confusing given that the third-party shyft.ai listing claims CodeWisp supports "cross-platform publishing (web and mobile)" — a user who saw that elsewhere will reasonably expect a working app here.
The fix: Label the nav item "Mobile (Coming Soon)" or move it out of the primary nav until the app ships. Add a target ship quarter to /mobile-app so the waitlist conversion is grounded.
10. /create offers no prompt guidance, examples, or in-product help, and ships a run-together button label (significant)
Problem: The core product surface ("Create Your Game") contains only the headline "Create your game in minutes," a "Best Quality" callout, an "Or start from a template" option, and what appears to be a run-together "BackCreate Game" button label (likely missing whitespace between two adjacent buttons). There is no empty-state guidance about what kinds of prompts work, no example prompts, no documented model differences (Fast / Standard / Best are mentioned on /credits but never explained), and no "what is supported" reference.
Consequence: Users — many of them children per the Terms' age-13 minimum — are dropped into a blank prompt input with no idea what to type. The credits page warns that builds cost 500–1,500 credits and a bad prompt is non-refundable, so the lack of prompt guidance directly burns the free-tier daily 800 credits. The "BackCreate Game" rendering glitch is a small but visible quality signal on the page that matters most for conversion.
The fix: Add an empty-state with 3–5 starter prompts, a one-line explainer of Fast/Standard/Best models and their credit cost ranges, and fix the run-together button label. Cross-link to the /discuss "Help" tag and the /faq from the empty state.
11. No documented support path for credits, billing, or AI output disputes (significant)
Problem: The only contact emails published are legal@codewisp.ai (used for legal/CCPA/arbitration opt-out in /terms and /privacy) and fuelvin@codewisp.ai (Enterprise sales contact on /pricing). There is no support@, help@, or billing@ address. There is no documented support path for "I was charged but my credits didn't refresh," "the AI generated something offensive that the Terms say can happen — what do I do," or "my game was removed." The /discuss forum has a "Help" tag but no SLA, no staff identification, and is not linked from /pricing or /credits.
Consequence: A paying Creator/Pro subscriber encountering a credit-accounting bug has no published path to resolution other than emailing the legal address or posting in a community forum. For a product with Stripe-billed monthly subscriptions and non-refundable fees (Terms section 7), the absence of a support contract is a churn risk and a chargeback risk.
The fix: Publish a support@codewisp.ai (or equivalent) contact and a /support or /contact page that maps issue types (billing, credits, content, abuse) to channels. Link it from /pricing, /credits, and the footer.
12. Deletion semantics for AI training are split across Terms and Privacy with no cross-reference (significant)
Location: /terms section 3 vs /privacy section 5 retention table
Problem: The Privacy Policy's retention table tells users that "Projects, code, chat messages" are kept "Until you delete the project or your account" and that "AI chat messages — Stored with the project they belong to" — i.e., deleting a project deletes its chat history. Terms section 3 separately states that when a user deletes content, the license ends "subject to reasonable technical delay for backups, to copies other users have already created (e.g., forks), and to AI models that were trained using Your Content before deletion (which we are not required to retrain or roll back)." Neither document cross-references the other.
Consequence: A user reading only the Privacy Policy's deletion table reasonably concludes that deleting a project erases their AI chats and prompts from CodeWisp's systems. Reading the Terms alone reveals that prompts already used for model training are retained in the resulting model weights indefinitely. The two correct statements only resolve to the truth when read together. For users 13–17 (the Terms' minimum age) and California residents exercising CPRA deletion rights, "what does delete actually mean" is exactly the question the retention table should answer end-to-end.
The fix: Add a single explicit statement to the Privacy Policy retention row for AI chat messages: "Deleted prompts may persist in trained model weights and are not rolled back; see Terms §3." Mirror the cross-reference back from Terms §3.
13. /pricing, /credits, and /faq carry no "last updated" date (minor)
Location: /pricing, /credits, /faq
Problem: Terms and Privacy both carry a clearly stated "Last updated on April 19, 2026" stamp. The product-policy pages — /pricing (which defines per-tier dollar amounts and credit allowances), /credits (which defines free-tier daily/monthly caps and per-action cost ranges), and /faq — carry no version or last-updated indicator.
Consequence: Credit costs and free-tier caps can be silently changed without any user-visible marker. A paying subscriber pointing to "what I was promised when I signed up" has no canonical record of what the page said on a given date, and AI agents summarizing the pricing have no signal that the prose may have shifted.
The fix: Add a "Last updated: <date>" stamp to /pricing, /credits, and /faq, set from the same source the Terms/Privacy dates are set from. Treat the credit cost ranges and free-tier caps as a versioned record.
14. Year-of-birth dropdown hard-codes 2013 as the cutoff (minor)
Location: /sign-up Step 1
Problem: The Year dropdown for date-of-birth offers 1900–2013. The Terms require users to be 13 or older, which in 2026 means anyone born in 2013 or earlier — currently correct. But the maximum year is baked into the rendered DOM rather than computed from the current date.
Consequence: Without a yearly update, the dropdown will silently bar eligible users in 2027 (children turning 13 born in 2014), 2028, and so on. A regression like this is invisible until someone complains they cannot find their birth year.
The fix: Compute the maximum year from currentYear - 13 at render time instead of hard-coding 2013.
15. Sign-up Step 2 markup has no password field (minor)
Location: /sign-up Step 2
Problem: Step 2 of the sign-up flow exposes Google sign-up plus an "or use email" alternative whose form fields, as scraped, are only Username and Email — there is no password field in the rendered markup, despite the /sign-in page exposing a password field and the Privacy Policy declaring that CodeWisp stores "password (hashed)" as account information.
Consequence: Either the password is collected on a later, unscraped step (in which case the documented flow does not match the markup that is publicly rendered) or the email flow relies on a passwordless verification step that is not documented anywhere. For a security-sensitive surface, the credential-capture step should be explicit in the same place the rest of the account form lives.
The fix: Either render the password field on Step 2 with explicit complexity requirements, or document the passwordless/magic-link flow in /faq and in the sign-up page itself so users know what to expect.
16. Terms list a SF street address that does not exist (minor)
Location: /terms section 18 and /privacy section 1
Problem: Both legal documents give the principal place of business as "1395 22nd St. Ave, San Francisco, CA 94107." "22nd St. Ave" is not a recognized SF street name — San Francisco has both "22nd Street" and "22nd Avenue" but not "22nd St. Ave."
Consequence: For a legal notice address — the address process servers, regulators, and DMCA agents use — an ambiguous or typo'd street name is a real problem. It may also raise an eyebrow for enterprise prospects doing diligence.
The fix: Correct the address to its real form (most likely "1395 22nd Street") in both Terms and Privacy, and verify the zip matches the actual street.
17. Terms covers codewisp.net as a separate service that no longer exists (minor)
Location: /terms section 1 and /privacy section 1
Problem: Both legal documents define the Services as "codewisp.ai, codewisp.net, and related services." In reality, https://codewisp.net is a 301 permanent redirect to https://codewisp.ai/ — it is not a separate service.
Consequence: Documentation hygiene: the legal definition references a domain that no longer corresponds to a separate product, leaving open the possibility that a future product on codewisp.net would be silently covered.
The fix: Remove the codewisp.net reference from Terms and Privacy, or document explicitly that codewisp.net is a redirect alias and no separate service is offered under it.
18. Blog undeclared in sitemap; third-party integration claims uncorrected (minor)
Problem: /blog has three live posts (all dated Apr 19, 2026, the same date Terms/Privacy were last updated) but is not declared in sitemap.xml and not linked from the site footer. Separately, a third-party listing (shyft.ai) claims CodeWisp integrates with "Unity, Unreal Engine, GitHub, Slack, Trello, Discord, Google Drive, and Zapier" and supports "cross-platform publishing (web and mobile)" — none of which are reflected in the Terms section 6 subprocessor list (only Supabase, Stripe, OpenAI, Anthropic, Google, Resend, PostHog) or anywhere on codewisp.ai.
Consequence: AI agents and prospects researching CodeWisp via third-party directories ingest false integration claims (Unity/Unreal/etc.) that the product does not have. The blog being absent from sitemap.xml means three pieces of marketing content do not get indexed.
The fix: Add /blog to sitemap.xml and link it from the footer. Publish a short /integrations page that lists what CodeWisp actually integrates with (or "no third-party integrations today") so the third-party directories can correct themselves.
What they do well
The Privacy Policy is unusually concrete for a YC W26 startup: a real subprocessor table with purposes and data shared, a real retention schedule with named windows (15-min reset tokens, 24-hr verification tokens, 12-month analytics), and explicit Global Privacy Control honoring.
The Terms make AI-specific risks (similar outputs across users, training on submitted content, third-party model providers) explicit instead of hiding them in boilerplate.
The /credits page is the one product surface that gives concrete, parseable numbers — daily/monthly caps, per-action cost ranges, and model-tier callouts — and is the best raw material for an llms.txt.
Top 3 recommendations
Reconcile /pricing and /credits and add both to sitemap.xml. Pick one canonical plan list and render both pages from it, then declare them in the sitemap so the pages that close the sale are actually discoverable. Today they advertise different sets of paid tiers and neither appears in the site's own discoverability manifest.
Ship an llms.txt + a real /docs (or /help) surface. Even a one-page docs hub that consolidates credit costs, model tiers, supported game types, and the support contact would unblock AI agents and stop the FAQ-only/JS-only support pattern.
Fix the consent surface and the footer's broken promises. Use one name ("Terms of Service") on /sign-up, the footer, and in link text — the document binds users to arbitration and a class-action waiver, so the consent label needs to match the agreement. Then publish /update-logs or remove it from the footer, add /courses to the nav, and give /referral and /create real public copy.