Premiers pas
Prompt Engineering for FloopFloop
Practical patterns and anti-patterns for writing prompts that get production-ready results from FloopFloop in one shot.
Dernière mise à jour :
Why prompt quality matters
FloopFloop turns a single text prompt into a production-ready web application. The model has to make a lot of decisions on your behalf — stack, layout, copy, data shape, integrations, error handling — and the only signal it has is what you wrote. A vague prompt produces a generic project; a specific one produces something close to what you had in mind. The good news: you do not need any prompt-engineering background to write specific prompts. Five small habits cover most of the gap.
This guide is the practical companion to Creating a Project. If you have not built your first project yet, start there. If you have, the patterns below explain why some of your prompts hit and others miss.
Anatomy of a great FloopFloop prompt
Every effective prompt answers six questions, in roughly this order:
- What kind of project is it? Landing page, dashboard, internal tool, bot, API, marketplace, etc. One short phrase is enough.
- Who is it for?“A solo freelance illustrator,” “a B2B SaaS sales team,” “my mum’s bakery.” The audience drives tone, complexity, and defaults.
- What does it do?List the core features as concrete verbs (“upload an image,” “show stock levels,” “send a daily summary email”) — not abstractions (“manage things”).
- What does it look like? Theme, accent colour, density (compact vs spacious), and any UI patterns you have opinions on (sticky CTA, dark mode, masonry grid, etc.).
- What data is involved? Where does it come from (a JSON file, a form, a third-party API), and what fields matter?
- What are the must-haves?One line at the end: “Mobile responsive, dark mode by default, accessibility score 95+.”
You do not need to write all six explicitly every time — but a prompt missing 4+ of them is the most common reason people are unhappy with their first build.
Five patterns that work
Pattern 1 — Concrete examples beat adjectives
Replace fuzzy adjectives like “modern,” “clean,” “professional” with a reference point: “in the style of Linear’s landing page,” “like a Notion sidebar,” “Stripe-style pricing cards.” The model has seen those references and will produce something visually closer to what you mean.
Pattern 2 — Name the data before the UI
Describe what data flows through the project before describing how it should look. “Each task has a title, status (todo / doing / done), assignee, and due date — show them in a kanban board with three columns and drag-to-reorder.” The model picks much better defaults when the schema is clear up-front.
Pattern 3 — One paragraph per surface
Multi-page or multi-view projects do best when you give one short paragraph per surface (home, dashboard, settings, login, etc.) instead of one long sentence covering everything. Linebreaks and paragraph headers like “**Home page**:” help the model section the work.
Pattern 4 — Lock down the integrations explicitly
If the project needs a third-party service — Stripe, Cryptohopper, OpenAI, a webhook — name it and say which secret holds the key (“read STRIPE_SECRET_KEY from project secrets”). This prevents the model from inventing a fictional integration or hardcoding a placeholder you have to find and replace later. See Secrets & Environment Variables for how to add the key.
Pattern 5 — End with constraints, not wishes
Constraints (“must work without JavaScript,” “keep total bundle under 200kB,” “no client-side secrets”) get acted on. Wishes (“should be performant,” “modern feel”) get ignored. Be specific about what cannot ship and the model treats it as a hard requirement.
Five anti-patterns to avoid
- The kitchen-sink prompt.“Build me a SaaS with auth, billing, dashboard, settings, admin panel, blog, and mobile app.” Too many surfaces in one shot dilutes quality on all of them. Build the smallest useful version first, then iterate.
- Stacking adjectives.“A modern, clean, sleek, beautiful, professional, minimalist landing page.” Adjectives stack instead of compounding — the result reads as generic. Pick one reference point and describe what you do not want instead (“not corporate, not playful — closer to Linear”).
- Naming a stack the platform does not use.Asking for “a Vue.js + Django app” will not change what FloopFloop ships (Next.js + TypeScript). Describe the behaviour you want, not the framework you would have picked manually.
- Hidden assumptions.“Like the one we discussed,” “the usual fields,” “you know what I mean.” The model has no shared context with you yet — spell out anything a freelancer would have to ask about.
- Negative-only prompts.“Don’t use blue, don’t make it boring, don’t put a hero section.” Tell the model what the project IS, then add negatives at the end if needed.
Iterating after the first build
The first build is rarely the last. After your project is live, use the project chat (see Chat & Refinement) to iterate. The same prompt principles apply, with one addition: refinement prompts should be scoped. Instead of “make the homepage better,” say “on the homepage, replace the testimonial carousel with a logo grid of 8 customer logos and add a sticky CTA in the top-right.” Scoped refinements land cleanly without regressing other parts of the project.
If you queue several refinements while a build is in progress, see Message Queue for how to reorder, edit, or remove them before they run.
Before vs. after
Two real prompts that produced very different first builds, both for the same product idea (a freelance-invoice tracker):
Vague prompt
“Build me an invoicing app for freelancers. Should look professional and let me track invoices.”
Result: a generic dashboard with three placeholder invoices, no data model, no clear next step.
Specific prompt
“Build a single-user invoice tracker for freelance designers. Each invoice has: client name, project, amount in EUR or USD, sent-date, due-date, status (draft / sent / paid / overdue), and a PDF download. The home view is a table of invoices with status chips and a filter bar (status + client). A ‘New invoice’ button opens a side-drawer form. Use a clean light-theme UI in the style of Linear, with a single accent colour I can change later. Mobile-responsive, no auth needed (single-user). Save data to localStorage for now — I’ll connect a database in a follow-up.”
Result: a working invoice tracker with the right schema, an interactive form, status filtering, and a sensible visual style — ready to share with a client the same day.
Frequently asked questions
How long should my prompt be? 3–6 short paragraphs is the sweet spot for a first build. Shorter is fine for simple single-purpose projects (a single landing page); longer is fine for multi-surface projects but break it into paragraph headings.
Will the model ask me clarifying questions if my prompt is unclear? No — FloopFloop builds in one shot from your prompt. Anything the prompt does not specify, the model will pick a reasonable default for. If you want a back-and-forth conversation before the build starts, write your prompt by chatting with another LLM first, then paste the refined version into FloopFloop.
Can I include code or screenshots? Code snippets help — paste the data shape you want, an API contract, or a small example function. For screenshots, use the attachment button in the prompt field; the model can use them as a visual reference for layout and style. See Attachments & File Uploads.
What about non-English prompts?Prompts in any language work, but the model produces stronger results in English and the generated UI copy is English by default. If you want the generated app’s UI in another language, say so explicitly (“The app interface should be in Dutch”).
How do I see what the AI actually picked up from my prompt? The first message in the project chat is your prompt verbatim, and the next message is the model’s plan before it starts coding. Read that plan — if it lists features you did not ask for, or skips ones you wanted, you can stop the build and refine before any code gets generated.