> ## Documentation Index > Fetch the complete documentation index at: https://docs.mythos.new/llms.txt > Use this file to discover all available pages before exploring further. # Writing good prompts > How to phrase your first Mythos prompt — name the sections, tone, and industry, flag any data-saving form, and use Plan mode to shape the build first. A Mythos prompt is a brief, not a spec. You describe the site you want in plain language and the builder turns it into a real React or Next.js page. The clearer the brief, the closer the first build lands — and the fewer follow-up edits you spend credits on. This page is about getting that first build right. **Cost:** a new project costs **3 credits**; each edit costs **2**. New accounts start with **5 free credits**. A sharper prompt means fewer edits, which means fewer credits — see [Credits & pricing](/introduction/credits-and-usage). ## Why prompt carefully The builder writes real, industry-specific copy and picks a palette, fonts, and section layout from your words. If you leave those open, it decides for you. Naming what you care about up front means you spend your first 3 credits on a result you can ship or lightly tweak, instead of three rounds of "make it darker, change the font, add a pricing section." ## What to put in a prompt The builder responds to four things. Cover the ones you care about; let it decide the rest. | Say this | Example | Why it helps | | ------------------------------- | ---------------------------------------------------- | ------------------------------------------------------------------- | | **The kind of site + industry** | "a landing page for a dental clinic" | The builder writes real copy for *that* industry, not lorem ipsum | | **The sections** | "hero, services, pricing, testimonials, FAQ, footer" | Each becomes its own component; naming them sets the page structure | | **The tone / look** | "clean and minimal" / "dark and industrial" | Drives the palette, fonts, and layout density | | **Any form that saves data** | "a quote-request form that stores submissions" | Tells the builder you need a real backend (see below) | Name the sections in the order you want them down the page ("hero, then services, then pricing…"). The builder renders them top-to-bottom in roughly the order you list. ## Example prompts A vague prompt and a good prompt for the same idea: ```text theme={null} Make me a website for my moving company. ``` ```text theme={null} Create a landing page for a moving company called Iron Anchor. Sections: hero, services, pricing, testimonials, a quote-request form, and a footer. Dark, industrial tone — heavy type, lots of contrast. ``` A few more that work well because they name the industry, the sections, and the tone: ```text theme={null} A portfolio site for a freelance photographer. Hero with a full-bleed image, an about section, a gallery grid, and a contact section. Calm, editorial, lots of whitespace. ``` ```text theme={null} A landing page for a SaaS tool that schedules social posts. Hero with a headline and CTA, a features grid, how-it-works, pricing with three tiers, testimonials, FAQ, and a footer. Bright and modern, blue accent. ``` ```text theme={null} A one-page site for a neighborhood coffee shop. Hero, our story, the menu, opening hours, and a map placeholder with the address. Warm and cozy, cream and brown palette. ``` ## If a form must save data By default the builder makes forms that *look* real but don't store anything — they validate and show a success message. That's fine for a marketing page. If you actually need submissions saved (a booking, a waitlist, a contact form you'll read later), that needs a **backend**, and Mythos builds the **frontend** only. **Mythos builds the frontend; data lives in your own Supabase.** To make a form store real submissions, connect **your own Supabase project** under Services → Cloud. Once it's connected, the builder wires the form to a real table in your database — including row-level security on every new table. So there are two paths: * **Just a marketing page?** Don't mention saving data — the builder makes a clean, working-looking form and you're done. * **Need the data?** Connect Supabase first, then ask. With a backend connected, the builder is proactive: it creates the table and wires the form to it in the same build. ```text theme={null} Add a waitlist form to the hero — name and email — and save each submission to my database. ``` That prompt only does what it says **if a Supabase project is connected**; without one, the builder builds the form but can't store anything and will tell you so. ## One page at a time A first prompt should describe **one page**, well. A multi-page site is several times the work, and the builder defaults to a single landing page unless you explicitly ask for more routes. Build the main page first, then add pages by chat: ```text theme={null} Add an "About" page with the team and our history, linked from the nav. ``` ## How Plan mode helps If you'd rather shape the build before spending credits, turn on **Plan mode** next to the send button. Instead of building straight from your prompt, Mythos walks you through a short flow — all **free**. Only the build after approval costs credits. Toggle **Plan mode** next to the send button, then send your prompt as usual. Mythos asks about services, palette, typography, and whether you need a data-saving form. It generates **three real design directions** — choose the one you like by sight. It shows a short plan; approve it to start the build. Only this final step costs credits. **Build mode vs Plan mode.** Build mode builds directly from your prompt — fastest. Plan mode questions → designs → plans first, so you choose the look by sight before any code exists. See [Plan mode](/features/plan-mode). Plan mode is worth it when you're unsure about the look, or when the first build matters enough that you'd rather pick from three options than describe a palette in words. A still-vague prompt makes Plan mode's questions and designs sharper, so the two work together. ## Good to know * **The builder picks what you don't.** Colours, exact layout, and section copy are decided for you unless you name them. You don't have to specify everything — only what you care about. * **Real copy, real industry.** Mention the industry and the builder writes specific copy for it. Skip it and the copy is more generic. * **Stock photos are used sparingly.** The builder adds a few photos where they help (a hero, one gallery), not one per section — asking for "an image in every section" works against a clean result. * **You're not locked in.** Anything the first build gets wrong is an edit away. See [Fixing a build that isn't right](/prompting/debugging). ## FAQ Detailed enough to name the kind of site, the industry, the sections you want, and the tone. Beyond that, let the builder decide — over-specifying every colour and pixel rarely helps and the result is one edit away anyway. Only if you've connected your own Supabase project under Services → Cloud. Without a backend, forms look and behave correctly but don't store anything. Connect Supabase, then ask for the data to be saved. You can, but it's not recommended for a first build. The builder defaults to one landing page; describe that page well, then add routes by chat. One strong page beats a thin version of five. The builder chooses a palette and type pairing that fit the tone and industry you described. If you have a specific look in mind, name it — or use Plan mode to pick from three rendered options. No. A build costs 3 credits regardless of prompt length. A clearer prompt is cheaper overall only because it tends to need fewer follow-up edits. ## Related * [Plan mode](/features/plan-mode) — shape the look and plan before the build runs. * [Fixing a build that isn't right](/prompting/debugging) — how to phrase corrections, revert, and when to edit code directly. * [Quick start](/introduction/getting-started) — the full first-build flow. * [Credits & pricing](/introduction/credits-and-usage) — what each build and edit costs.