Prompt examples
Real prompts beat abstract advice, so this page collects worked examples for common builds: a services site, a store, a client portal, an internal tool, and an invoicing app, plus follow-up edits and answers to Roc's questions. Copy any of these, swap in your own details, and adjust. The pattern to notice throughout is the same one from Best practices: a name, real business details, and outcomes rather than implementations.
A services business with booking
Build Bright & Even, a website for my teeth whitening studio in Gothenburg.
Services: express whitening (45 min, 1200 kr), full treatment (90 min, 2100 kr),
and a touch-up for returning clients (30 min, 700 kr). Customers should pick a
service and book a time slot, and I want to see all bookings in an admin area
only I can access. Warm and friendly style, we get a lot of nervous first-timers.
Why it works: the name gives Roc a brand, the services with durations and prices become real content instead of placeholders, the booking and admin requirements are stated as outcomes, and the style line ("warm and friendly", "nervous first-timers") gives the design a reason, not just a look.
An online store
Build Fjällgear, an online store for hiking equipment. Products have a name,
photo, price, and category (backpacks, tents, cooking, clothing). Visitors browse
by category, add items to a cart, and pay by card at checkout. I manage products
from an admin page. Dark and modern, big product photography.
Why it works: it lists the product fields, which shapes the database, and it names the three user flows that matter (browse, cart, checkout) without prescribing how to build them. Card payments need the Stripe integration, and Roc will point you to it.
A client portal with login and payments
Build Ledger & Pine, a client portal for my bookkeeping firm. Clients sign in
with email or Google, see only their own documents and invoices, and can pay an
invoice by card. I upload documents for each client and mark invoices as paid or
unpaid. Elegant and minimal, this is for business clients.
Why it works: "see only their own documents" is the key sentence. It tells Roc the data is private per client, which drives sign-in, table visibility, and the payment flow being tied to a signed-in user.
An internal tool
Build Dispatch Board, an internal tool for my cleaning company's 6 field teams.
Each job has a customer, address, date, assigned team, and status (scheduled, in
progress, done). The office creates jobs, teams sign in and update the status of
their own jobs, and I want a dashboard showing today's jobs per team. Nobody
outside the company should see anything.
Why it works: the job fields, the two roles (office and teams), and the privacy requirement are all explicit. Internal tools live or die on who can do what, so say it plainly.
An invoicing app
Build Kvitto, an invoicing app for my freelance design work. I create clients
and invoices with line items, quantities, and unit prices, and it calculates
totals with 25% VAT. Each invoice gets a number like 2026-014 and a status of
draft, sent, or paid. Clients get a link where they can view the invoice.
Why it works: numbering format, VAT rate, and statuses are the fiddly details a generic invoicing prompt leaves to chance. Specifying them gets them right on the first build.
Follow-up edits: good versus vague
Once the app exists, small and specific wins.
| Vague | Better |
|---|---|
| Make it better | Make the hero headline shorter and move the booking button above the fold |
| Fix the pricing | On the pricing page, change the full treatment to 2300 kr and add "most popular" to it |
| The form is bad | On the contact form, make email required and show a thank-you message after sending |
| More professional | Replace the playful icons with simple line icons and tighten spacing on the services grid |
The vague versions force Roc to guess what bothers you. The better versions name the page, the element, and the outcome.
Grounding with a URL
Here is my current site: https://www.brightandeven.se. Rebuild it on Instroc
with the same services, prices, and about text, but modernize the design and
add the booking flow we discussed.
Roc reads the page and uses your real content, so nothing needs retyping.
Answering Roc's questions
On a new build Roc asks 2 to 4 quick questions. Short, decisive answers work best:
- What should we call your app? "Bright & Even"
- What visual style fits? "Warm and friendly, soft colors, nothing clinical"
- Should clients pay when booking or at the studio? "At the studio, booking is free"
You can press Skip on anything you have no opinion about, or say "just build it" to skip them all and let Roc choose defaults. If something goes sideways after a build, head to Troubleshooting.