# Ship a Digital Business Website: start prompts Paste this into your AI after you get Ship a Digital Business Website. There are two prompts. Paste the first one in the session where you start using the journal on your site. Paste the second one at the start of every later session, so your AI picks up where it stopped. ## Prompt 1: first session (read, map, audit) ```text I bought the journal "Ship a Digital Business Website". It is a field manual written from many live stores: the full pipeline for a site that browses, takes money, delivers files or access, emails buyers and tracks conversions, plus the bugs that cost real money and how they were fixed. Your job is to read it, map my project onto its pipeline, and help me build or repair my site in the journal's order, one step at a time, checking each step the way the journal says. WHAT IT IS FOR Building or fixing a site that sells digital products, licenses, subscriptions or access. Use it for the site shell, database and login, the catalog, checkout, the payment webhook, gated downloads, email, lead capture, conversion tracking, the admin page, deploys and getting indexed. WHEN TO USE IT - Before you write or change anything on the money path: checkout, webhook, entitlement, download, emails, coupons, prices. - Before every deploy, and after it (the journal's live audit). - When I say "nobody buys", "the button does nothing", "a buyer cannot download", "the email did not arrive", "the numbers look wrong". HOW TO GET AND READ THE JOURNAL - With the Vibedna connector: call list_library, find the slug ship-a-digital-business-website, then read_journal(slug="ship-a-digital-business-website", part=1), then part=2, 3 and so on until there are no more parts. Read every part before you propose changes. - With Journals DNA paired: journal_get(slug="ship-a-digital-business-website") writes it into ~/.journal/library; read it from there with journal_read (use offset and limit). - Read in this order: "What this is" and "How to read the decisions here" first (every choice is a known-working starting point, not a benchmark: verify it against my case). Then "The pipeline, end to end" and its "Architecture rules". Then the section for whatever step we are on. Before any change, check "Bug to root cause to fix catalog" and "Decisions and the reasoning" (including "What we killed, when, and why"). If the journal has dated entries at the end, they are the newest lessons and win over older text. ASK ME FIRST (only what the journal says decides the build) 1. What do I sell: one-time items, lifetime access, subscriptions, bundles, or a gated feature? Files or access? 2. Which stack: the default (Next.js on Vercel with Supabase) or the content-site path (Astro on Cloudflare Pages)? Or my own existing stack (then keep it and apply the lessons)? 3. Which payment processor or processors, and is my product's category allowed by each? (The journal: read every processor's prohibited list before building; an account can work for days and still be suspended.) 4. Do I offer PayPal next to cards? Where do my visitors come from (ads opening inside social apps behave differently)? 5. Is my database shared with any other brand or site? 6. Which email provider and which sending domain? THE PIPELINE, IN THE JOURNAL'S ORDER (each step assumes the one before it works) 1. Site shell live on a public page. 2. Data and auth: one database, row level security on every table, magic-link login (with a one-time code in the same email). 3. Catalog: products are database rows with a stable readable string id, never a random UUID; prices read from the database, never hardcoded. 4. Checkout: a hosted or embedded checkout created server-side from a catalog item, through one internal endpoint so the processor can be swapped in one place; payment code ships inert until its keys exist. 5. Fulfillment webhook: verify it is real, record the purchase idempotently, create the account if missing, grant the entitlement, send the delivery email. Every purchase shape (one-time, subscription, renewal, add-on, refund) reaches the same records. 6. Gated delivery: files behind an entitlement check and a short-lived signed URL, with the right file extension; or a magic link into the library. 7. Email engine with your own open and click tracking. 8. Email capture everywhere, each capture starting a welcome sequence. 9. Conversion tracking: browser pixel plus server-side events with a shared event id. 10. Admin page, hidden and gated by an allowlist plus proof of the address. Then: buy your own product, automate the payment test, deploy with a live audit, and get the domain indexed. HOW TO VERIFY EACH STEP (the journal's own tests) - Verify by charging, never by rendering: a page that returns 200 with the right price can still have a dead buy button. - A payment test only counts if it pressed Pay. Test the gate in both directions: a real, valid webhook delivery gets a 200, and the endpoint is actually registered with the processor. - Proof is behaviour: a real download, a real email read in a normal inbox on a phone, a cron's own count. An environment variable that "exists" can be empty. - After a catalog change, load an existing buyer's library, not the storefront. - Test every buyer path in a private window with a throwaway email (your own admin bypass hides buyers' bugs), and in an iPhone browser as well as Chrome. WHAT TO CHECK FIRST The live state, not my notes: which keys are set in production (and that the served page carries exactly one live publishable key and no test key), which webhook endpoints are registered on the processor account and which events they receive, whether every coupon and price id exists in live mode, and whether the site's public base URL points at the real domain. NEVER - Never spend money, run a real purchase, send an email to my list, deploy to production, change a live price or coupon, or delete anything without my yes in this session. Show me the exact change first. - Never delete a product that anyone bought: retire it by hiding it. - Never let anything cover the buy button, and never gate the payment button on background work. - Never swallow a checkout error in a silent catch: make it visible and log it. - Never trust the processor's amount field or the ad pixel for revenue: my own purchases table plus the processor's API are the source of truth. - Never share one database project across my two most valuable brands, and never change a shared project's site URL. - Never deploy from a local machine with .env.local in the upload, never mark a public variable as sensitive, and never leave a fallback secret in code. - Never write keys, passwords or tokens into a file, a journal or this chat. Code reads them from environment variables. KEEP MY PROJECT JOURNAL - If I have Journals DNA: after each step, journal_append(name_or_path="", entry="", tag="ship" or "fix"). When I choose something (processor, stack, price, a rule), journal_decision_add(name_or_path="", decision="...", why="..."). When the state changes, journal_update_section(name_or_path="", "Current state", new_content, mode="replace"). - If I do not: keep a plain _JOURNAL.md in my project folder and add a dated line for each step done, each decision and each bug with its root cause. HOW TO REPORT BACK Result first, in plain words: which step, what you changed (file by file), how you proved it works. Name the journal section you relied on. End with one question if something needs my decision. FIRST TASK NOW Read part 1 of the journal (and the rest before proposing anything). Ask me the six questions above. Then audit my project against the ten pipeline steps and the buy-your-own-product loop, reading my code and the live site only: for each step say done, missing or broken, with the evidence. Change nothing yet. End with the one step you would do first and why. ``` ## Prompt 2: every later session (continue) ```text We are building my site with the journal "Ship a Digital Business Website". Continue from where we stopped. 1. Read my project journal first (journal_handoff_brief("") if I have Journals DNA, or my _JOURNAL.md). Tell me in five lines which pipeline steps are done, which one is next, and what is waiting on me. 2. Re-open the journal section for the next step (read_journal with the part that holds it, or the copy in ~/.journal/library) and its rows in "Bug to root cause to fix catalog" before you touch anything. 3. Check the live state of that step before you trust what my journal says it was. 4. Do one step, verify it the way the journal says (charge, press Pay, real download, real email), log it with journal_append, then stop and show me. 5. Before any deploy: clean working tree, then the journal's live audit after it (key pages 200, buy button reachable on phone and desktop, payment opens, live key in the served code, a database read), then the payment test. Deploys, real purchases, emails to my list and price or coupon changes wait for my yes. 6. At the end of the session, replace the Handoff section of my project journal: what is done, what is next, what is blocked by me. ```