LaunchFast ships a polished, multi-framework (Astro / SvelteKit / Next.js) starter-kit and a clean Starlight docs site — but the docs systematically defer the one thing developers actually need (environment-variable configuration) to GitHub repos that return 404, several copy-paste code examples are broken as written, and several headline marketing features (Analytics, Polar/Creem payments, subscriptions, Render deploys) have no documentation at all.
1. The only place env-var names exist is a GitHub repo that 404s for anyone who hasn't purchased (critical)
Problem: The Setup page's only instruction for configuring the database is: "Open the .env file and update the DATABASE_TYPE and the relevant database provider environment variable(s) per the following instructions" → https://github.com/LaunchFast-Boilerplates/launchfa.st-astro#database (and the SvelteKit/Next.js siblings). That repo returns HTTP 404 to anonymous/unpurchased users (verified via HEAD request and WebFetch — both 404 Not Found). The same pattern repeats across the docs: the Postgres page links to #database, the S3 page links to #storage, and the OAuth and Postgres pages' "Browse the source code here" links point into the same dead repo (/blob/master/auth.config.ts, /blob/master/src/lib/db/index.ts). The doc pages themselves list no environment-variable names at all — every page says "update the environment variable(s) per the following instruction" and links out.
Consequence: A prospective or newly-onboarded developer cannot configure a single provider from the documentation. The entire setup path bottoms out at a 404. There is no fallback list of variable names anywhere in the docs, so even someone who owns the repo learns nothing from the doc page — and an AI coding agent indexing the docs hits a wall with zero structured config to extract.
The fix: Put the actual environment-variable names and example values directly in each doc page (DATABASE_TYPE, the Postgres URLs, S3 keys, Resend API key, etc.) in a parseable code/table block. Reserve the GitHub link as supplementary "full source" reference, not the canonical config source. At minimum, mirror the repo READMEs' #database/#storage sections into the public docs.
2. Resend email example references an undefined context variable — it cannot run (significant)
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.
Problem: The handler is declared as export async function GET({ request }: APIContext) — it destructures request. But the body references context.text, context.subject, and context.to:
The variable context is never declared or destructured. The same undefined context appears in both the GET and POST examples.
Consequence: Anyone who copies this example verbatim gets a ReferenceError: context is not defined at runtime. This is the canonical "send an email" example for the product's transactional-email module, so it's a first-run failure for a core feature. An agent extracting and running it fails silently.
The fix: Make the signature and body consistent — either destructure { request } and parse the body (const { text, subject, to } = await request.json()), or accept the full context: APIContext and reference context.request. Also replace the hard-coded from: 'Rishi Raj Jain <emails@rishi.app>' (the author's personal address) with a clearly-marked placeholder like you@yourdomain.com.
3. Cloudflare deploy steps are out of order — Step 1 deploys before Step 2 creates the config it needs (significant)
Location: /documentation/deployment/cloudflare
Problem: The numbered steps run in an impossible order:
Step 1: "Deploy to Cloudflare Workers with the following: npm run build && npm run cloudflare:deploy"
Step 2: "Create a copy of wrangler.toml.example as wrangler.toml"
Step 3: "set all the environment variables in wrangler.toml"
Step 4: "Finally, deploy to Cloudflare Workers (again)"
A reader following the steps in order attempts to deploy before wrangler.toml exists and before any env vars are set. Step 4 then repeats the identical command labeled "(again)."
Consequence: Following the documented order produces a failed/misconfigured first deploy (no wrangler.toml, no env vars). The redundant Step 1 is pure confusion — developers will deploy a broken build, then have to figure out the ordering themselves.
The fix: Reorder to: (1) create wrangler.toml from the example, (2) set env vars, (3) build + deploy. Delete the premature Step 1.
4. Postgres doc omits the two env vars the changelog says are now required (significant)
Problem: The changelog states: "To use Postgres as your database, you now need to specify both POSTGRES_POOLED_URL and POSTGRES_DIRECT_URL environment variables." Neither variable name appears anywhere on the Postgres doc page — which only says "update the environment variable(s) of your application per the following instruction" and links to the 404 repo.
Consequence: A developer reading the current Postgres doc has no way to learn that two distinct connection URLs are required. They'll likely configure a single DATABASE_URL-style value and hit a connection failure, with the contradicting requirement buried in a dated changelog entry rather than the reference page.
The fix: Add both POSTGRES_POOLED_URL and POSTGRES_DIRECT_URL (with an example and an explanation of pooled vs. direct) directly to the Postgres doc, and keep it in sync with changelog-announced changes going forward.
5. Analytics is a headline feature with zero documentation (significant)
Location: Marketing home ("Analytics" module) vs /documentation (full sidebar)
Problem: The home page advertises an Analytics module wired to four providers: "Wire PostHog, Pirsch, Google Analytics, or Wide Angle on day one." The complete docs sidebar (verified identical from two pages) has sections for Authentication, Emails, Database, Storage, and Deployment — but no Analytics section anywhere in the nav, and no analytics page surfaced at any URL in the scraped content.
Consequence: A buyer who chose LaunchFast partly for "day one" analytics has no instructions to enable any of the four providers, configure tracking, or verify events. The feature is sold but undiscoverable in the docs.
The fix: Add an Analytics section to the docs with one page per provider (PostHog, Pirsch, Google Analytics, Wide Angle), including the env vars and the component/snippet used to enable tracking.
6. Payments docs are orphaned and cover only 2 of 4 advertised providers — no Polar, no Creem, no subscriptions (significant)
Problem: The marketing site advertises "Subscriptions, one-time payments… Use Stripe, Lemon Squeezy, Polar, or Creem." The only payments doc that exists is /documentation/tutorials/one-time-payment, which: (a) is not in the docs sidebar (orphaned); (b) returns 200 while /documentation/payments and /documentation/payments/stripe are reported to 404 (no archived status code is in the evidence, so this is reported rather than independently verified like the GitHub repo); (c) covers only Stripe and Lemon Squeezy — there is no Polar doc and no Creem doc; and (d) is titled "One-Time Payment" with no subscriptions guide despite subscriptions being advertised. The Lemon Squeezy example also hard-codes a live checkout URL with an embedded discount code: product_url="https://launchfast.lemonsqueezy.com/checkout/buy/30dd570f-...?checkout[discount_code]=M0OTIWMA".
Consequence: Two advertised payment providers (Polar, Creem) and the entire subscriptions billing model are undocumented. The one payments page that exists isn't reachable through navigation, and the copy-paste Lemon Squeezy snippet points at the author's own live store with a real discount code rather than a placeholder.
The fix: Create a Payments section in the sidebar; add Polar and Creem pages; add a subscriptions guide distinct from one-time payments; fix the missing /documentation/payments* routes (or stop linking them); and replace the live Lemon Squeezy checkout URL + discount code with a clearly-marked placeholder.
7. Render is an advertised deploy target with no deployment doc (significant)
Location: Marketing home ("Deploy Anywhere") vs /documentation/deployment sidebar
Problem: The marketing site's Deploy Anywhere section lists "Vercel, Cloudflare Workers, Netlify, Render, Fly.io, or any Node.js host." The deployment section of the docs sidebar contains only aws-amplify, cloudflare, fly, netlify, and vercel — there is no Render page at any URL in the scraped content.
Consequence: A developer who selected LaunchFast partly because it advertises Render support has no deploy guide, no build/start command, and no env-var wiring for Render — the exact same docs-vs-marketing gap as Analytics and payments, on a named, promoted platform.
The fix: Add a /documentation/deployment/render page covering build/start commands and env-var configuration, or remove Render from the advertised deploy targets if it isn't actually supported.
8. Protected-API-routes example calls getSession without importing it (significant)
Problem: The Astro example (src/pages/api/test.js) calls const session = getSession(request) but contains no import for getSession. The SvelteKit variant on the same page correctly imports it: import { getSession } from '@/lib/utils/auth'. So the two halves of the same tutorial disagree on whether the import is needed, and the Astro half is missing it. Additionally the SvelteKit file path is given as src/route/api/test/+server.ts ("route", singular) while the surrounding prose says APIs live in src/routes/api (plural).
Consequence: Copying the Astro snippet yields getSession is not defined. The singular/plural path mismatch (route vs routes) sends SvelteKit users to a directory that won't be picked up by the router.
The fix: Add import { getSession } from '@/lib/utils/auth' to the Astro example, and correct the SvelteKit path to src/routes/api/test/+server.ts.
9. getSession has no canonical import path or call signature across the docs (significant)
Problem: The same auth helper is imported from different paths on different pages:
Private Page (Astro): import { getSession } from '@/lib/auth'
API routes (SvelteKit): import { getSession } from '@/lib/utils/auth'
Resend (sendEmail): import { sendEmail } from '@/lib/utils/email'
There is no single documented helper location. The call convention also differs: the Private Page Astro example uses getSession(Astro.request) while the API-routes Astro example uses getSession(request).
Consequence: Developers can't tell whether the helpers live under @/lib/... or @/lib/utils/..., so at least one of the copied imports will fail to resolve. The differing arguments (Astro.request vs request) compound the confusion about how to call the same function. Agents have no reliable module path to generate against.
The fix: Pick one canonical path for the auth/email utilities and use it everywhere; show the correct argument for each framework consistently. If both paths genuinely exist, document the distinction explicitly.
10. OAuth doc markets "20+ providers" but documents none of them (significant)
Location: /documentation/authentication/oauth
Problem: The page is titled "User Authentication with 20+ OAuth Providers" but provides no provider-specific environment-variable names or examples. The entire configuration is deferred: "Add (or update) the necessary environment variables per each OAuth guide in https://authjs.dev/getting-started/authentication/oauth," plus a "Browse the source code here" link to the 404 repo's auth.config.ts.
Consequence: A developer wanting to enable, say, Google or GitHub login gets no callback-URL guidance, no env-var names, and no LaunchFast-specific wiring — just a pointer to Auth.js's generic docs and a dead source link. The "20+ providers" headline is unsupported by any concrete instruction.
The fix: Document the LaunchFast-specific env vars and the /signin wiring for at least the providers shown on the marketing site (Google, GitHub, Facebook, Twitter/X), with callback URLs and example values. Keep Auth.js as a reference, not the sole instruction.
11. Changelog contains framework/URL mislabels and copy-paste churn (minor)
Location: /changelog
Problem: Several entries contradict themselves:
21 Apr 2026 — heading reads "LaunchFast Next.js Starter Kit" but the bullet says "use any MySQL connection with the LaunchFast Astro Starter Kit."
14 Mar 2025 — "We've shipped a changelog page (https://launchfast-sveltekit.launchfast.workers.dev/changelog) to the Astro starter kit" — a SvelteKit URL attributed to Astro.
4 Dec 2024 — doubled-word typo: "Replace Polar with Lemon Squeezy checkout links checkout links."
The Polar↔Lemon Squeezy checkout links were swapped to Polar (24 Nov 2024) and back to Lemon Squeezy (4 Dec 2024) within ~10 days, with no explanation.
Consequence: Readers can't tell which framework each change applies to, which undermines the changelog's purpose for a multi-framework product. The Polar/LS flip-flop also signals to a developer that the active payment provider is unstable, with no guidance on which is current.
The fix: Correct the Next.js/Astro heading mismatch and the SvelteKit-URL-attributed-to-Astro line, remove the doubled words, and add a one-line rationale when a provider is swapped so the timeline reads coherently.
12. Introduction demo links jump to a different demo host for one item (minor)
Location: /documentation/guides/introduction
Problem: Every demo link points to launchfast-astro.launchfast.workers.dev (landing, careers, dashboard, protected, blog, etc.) except the "Documentation pages" link, which points to a different host: launchfast-nextjs.launchfast.workers.dev/docs.
Consequence: A reader exploring the Astro demo is silently bounced to the Next.js demo for the docs example, making it look like the Astro starter has no docs feature.
The fix: Point the "Documentation pages" link at the same Astro demo host as the rest of the section, or clearly label that it intentionally shows the Next.js demo.
13. Marketing feature lists understate the docs — MySQL and AWS Amplify are documented but never advertised (minor)
Location: Marketing home ("Bring Your Own Database" / "Deploy Anywhere") vs /documentation sidebar
Problem: The docs sidebar includes /documentation/database/mysql and /documentation/deployment/aws-amplify, and the 21 Apr 2026 changelog announces MySQL/MariaDB support. But the marketing database list is only "PostgreSQL, MongoDB, Redis, SQLite, Firestore" (no MySQL), and the marketing deploy list is only "Vercel, Cloudflare Workers, Netlify, Render, Fly.io, or any Node.js host" (no AWS Amplify).
Consequence: The reconciliation cuts both ways: a developer evaluating LaunchFast for MySQL or AWS Amplify can't tell from the advertised feature lists that either is supported, so a real, documented capability goes unsold.
The fix: Sync the marketing feature lists with the docs — add MySQL and AWS Amplify to the advertised providers, or explain why they're documented but not promoted.
14. Setup prerequisites give a single blanket Node.js floor for three different frameworks (minor)
Location: /documentation/guides/launch
Problem: Prerequisites list "Node.js (v18 or higher)" as a flat requirement for all three starters (Astro, SvelteKit, Next.js). The docs state no per-framework minimum and never reference each starter's engines field, so a reader can't tell whether v18 actually satisfies the framework version each starter is built on.
Consequence: A developer on a stock Node 18 install may hit engine/peer-dependency errors during npm install or build despite "meeting" the stated prerequisite, with no per-framework guidance in the docs to diagnose it.
The fix: State the exact minimum Node version each starter supports (verified against each repo's engines field), and recommend an LTS such as Node 20/22 rather than a single blanket "v18 or higher."
What they do well
The product ships a genuine llms.txt with both abridged (llms-small.txt) and complete (llms-full.txt) documentation sets, auto-generated from the same source as the official docs — solid agent-friendly groundwork.
Code examples are consistently shown across all three frameworks (Astro / SvelteKit / Next.js), which is the right structure for a multi-framework starter kit.
The docs are organized into clear provider-per-page sections (databases, storage, email, deployment) that match the modular "use what you need" pitch.
Top 3 recommendations
Inline the environment variables. Stop deferring config to GitHub repos that 404 for unpurchased users — put every provider's env-var names and example values directly in the doc pages (Findings 1, 4, 10).
Fix the broken copy-paste examples. The Resend (context undefined), API-routes (missing getSession import, route vs routes), and Cloudflare (out-of-order steps) examples fail as written; reconcile the helper import paths to one canonical location (Findings 2, 3, 8, 9).
Close the docs-vs-marketing gap in both directions. Document the features you sell (add an Analytics section, Polar/Creem payment pages, a subscriptions guide, and a Render deploy page), surface the orphaned payment/API/private-page tutorials in the sidebar, and advertise the MySQL/AWS Amplify support you've already documented (Findings 5, 6, 7, 13).