Solution · Bakery website
A landing page for your bakery, with a contact form that works
Describe your shop in plain English and watch a real website build itself in a live preview — complete with a contact form that emails you every enquiry.
For anyone · describe it → live, hosted app
At a glance
Is this the right pattern for you?
The short version, before the detail — who this is written for, what you start from, and what exists at the end.
| This solution | |
|---|---|
| Written for | Anyone who can describe what they want |
| You start from | A sentence describing the thing you want to exist |
| You end up with | A live, hosted application on a real URL |
| The path runs | Scope → build → preview → refine → Go Live |
| Built on | Prompt to app · Live preview · Managed backend · Go Live |
| Plan needed | Free to build and preview · Starter for a custom domain |
No timings are quoted anywhere on this page, because how long a build takes depends entirely on what you asked for.
The challenge
Why this is usually hard
Worth understanding before the how — because the reason this is difficult is not the reason most people assume.
Getting a simple business website online is supposed to be the easy part, and for most independent shops it is the part that never happens. The usual route is a page builder: you pick a theme, fight its layout rules, and end up with something that looks like every other shop on the same platform. The moment you want the one feature that actually matters — a contact form that reaches you — you hit a wall. Forms are a paid add-on, or a third-party widget with its own account, or a mail server you are expected to configure yourself.
So the compromise gets made. The website becomes a social profile, or a single page with a phone number and no way to take an order enquiry, or a half-finished draft that never gets published because the form never got wired up. None of that is a design failure. It is a plumbing failure: the parts that need an account, a credential or a bill are exactly the parts a one-person shop has no appetite to set up.
This pattern removes that entire class of decision. You describe the shop; the page, the sections and the working contact form are produced together, in one codebase, on a sandbox and a host that are already there. There is no separate form service to sign up for and no SMTP credential to paste — the form posts to a handler written into your own app, which sends through Resend on a key you supply. Nothing has to be reconciled between the thing you previewed and the thing your customers open.
How it works
From a sentence to a live app
Every stage in order, including the ones that happen without you asking.
- 1
Describe your bakery in one message
Build me a landing page for my bakery with a contact formGive it the shop name, what you sell, your opening hours and your town. That single description is the whole spec — you are not filling in a form or choosing a theme first. A complete page with a hero, menu highlights, hours, location and a contact section starts assembling immediately.
- 2
Answer a few scoping questions in chat
BlueprintA new project opens in chat before it opens any tabs. The agent asks about the parts of your idea it cannot guess — whether anyone needs to sign in, what gets stored, whether money changes hands — and fills in a blueprint as you answer. When there is enough to build from, the button changes to Review blueprint and the build starts from your confirmation. Nothing there is permanent; the blueprint is a starting point, not a contract.
- 3
Watch it build in the live preview
The page appears in a running preview as it is written, not as a static mockup. You can scroll it, click through it and read it on a phone-width view while it is still being worked on, so you catch the things that only show up in a real browser.
- 4
Refine it by pointing, not describing
promptOnce something exists, stop writing paragraphs about it. Click the heading, the image or the button you mean and say what should be different — warmer colours, bigger prices, a "specials this week" band above the fold. The edit lands where you pointed instead of somewhere approximate.
- 5
Match a look you already like
attach a screenshotIf you have a reference — a screenshot of a site you admire, a photo of your own flyer, a menu card — attach it and ask for the page to be restyled to match. Spacing, type and colour feel are taken from the reference rather than reinvented from a description.
- 6
The contact form gets a real mailbox
Transactional email is part of the managed stack, so the form is connected to real sending rather than left as a decorative input. Every submission is delivered to your inbox. You do not create a sending account, verify a domain or copy an API key to make that work.
- 7
Go Live
Go LivePublishing puts the same app you have been previewing on a real, public web address over HTTPS. There is no export step and no separate build configuration, so what you approved is what visitors get.
- 8
Point your own domain at it when you are ready
A custom domain can be connected from settings on a paid plan, without rebuilding the app. Until then the hosted address works perfectly well for a flyer, a social bio or a card in the window.
Why code-anything
What you get out of the box
Not a feature list — the specific things this pattern removes from your side of the work.
Nothing to set up first
No hosting to buy, no theme to choose, no plugin marketplace to navigate, no stack of third-party services to assemble before you can publish. You describe the page; the sandbox it builds in and the edge it is served from are already running, and the form handling is code in your own project.
A contact form that actually sends
Enquiries are delivered through managed transactional email on Resend, working from the very first submission. This is the piece that usually stalls a small-business site, and it is handled before you ask.
Edit by clicking, not by explaining
Point at any element in the live preview and describe the change. It is closer to talking to a designer looking at the same screen than to writing a change request and hoping it is understood.
A genuine hosted address
Go Live publishes to a real URL served from Cloudflare with HTTPS — something you can print on a flyer, hand to a supplier or point your own domain at, not a preview link that expires.
It is a real codebase, not a document
What gets built is an actual application, not a proprietary page-builder file. That matters the day you want something a template cannot do, because there is no ceiling to hit and nothing to migrate off.
Changing it later is the same conversation
New opening hours, a seasonal menu, a wedding-cake page — you ask for it the same way you asked for the original. There is no separate CMS to learn and no developer to book in.
In practice
What it looks like
This is the whole input. Not a brief, not a sitemap, not a set of field values — one message in the language you would use to describe the shop to a friend.
What comes back is a running page you can click through, and the loop from there is conversational: point at what is wrong, say what it should be, look again. The contact form is wired to real email before you think to ask about it, because that is the part that otherwise stops the project.
Build me a landing page for my bakery with a contact form.
We're "Rise & Crumb" in Brighton — sourdough, pastries and custom cakes.
Open Tue–Sun, 7am–3pm. Warm, cosy feel.✓ generated hero, menu highlights, hours and location sections
✓ applied a warm, cosy theme
✓ wired the contact form to transactional email
✓ running in the live previewWhat you ship
- A polished, mobile-friendly landing page written around your actual shop
- A contact form that delivers every enquiry to your inbox from the first submission
- Hours, location and menu highlights laid out so a customer finds them in one glance
- A real hosted URL over HTTPS that you can share immediately
- The option to point your own domain at it on a paid plan, without a rebuild
- A real codebase behind it, so nothing you want later is out of reach
- A way to make the next change that is identical to how you made the first one
What it involves
The honest shape of the path
Stage by stage: what the platform does, and what is genuinely still asked of you.
| Stage | What actually happens | What is asked of you |
|---|---|---|
| Scope | A new project opens in chat before any tabs appear. The agent asks about the parts it cannot guess and fills in a blueprint. | Answer the questions and confirm the blueprint. Nothing is permanent — you can change anything after the first build. |
| Build | The agent plans the work, writes the code and runs it, reaching for the data, auth, email or payments bricks only where the app actually needs them. | Nothing. You can pick a build quality — Prototype, Standard or Best — if you want fewer checks or more review. |
| Preview | A live preview mirrors the real running app, updating as it takes shape. | Look at it properly, including at phone width. This is where problems are cheapest to catch. |
| Refine | Click an element to target an edit, describe the change in chat, or attach a screenshot as a reference to match. | Judgement. This is the part that is genuinely yours, and pointing beats describing. |
| Go Live | The same app you previewed is published to a public URL over HTTPS on managed hosting. | One decision, plus a domain if you want one. Custom domains are included from the Starter plan upwards. |
The path is short because the writing, hosting and deploy steps are not yours to make. The time this takes depends on what you are building, so no page on this site quotes a number.
Describing an app and refining it in the live preview starts on the Free plan, which includes one active project and a managed database, auth and email. Publishing to your own custom domain is included from Starter upwards, and payments are a Pro-plan capability. See the full plan comparison.
What you own
What you are left holding
The thing this pattern produces is an application, not a document inside a builder. That distinction is easy to skip past and it decides what your options look like a year from now — so it is worth being concrete about what exists at the end.
What exists when you are done
- A real codebase, running on managed infrastructure rather than rendered inside a proprietary editor
- A live, public URL served over HTTPS on Cloudflare, with a custom domain available on a paid plan
- A managed Postgres database on Supabase if your app stores anything — standard Postgres, so the data stays queryable and portable
- Authentication, transactional email and payments already connected where the app calls for them
- A version history of build checkpoints on Repository → Changes that you can rewind to
What stays in your hands
- The next change is the same conversation as the first one — no separate CMS and no developer to book
- Nothing is written in speculatively, so a simple page stays a simple page
- A rewind snapshots the current state before it runs, so trying something is not a one-way door
- The preview is the app that ships — there is no export step and no gap between what you approved and what visitors get
FAQ
Common questions
Keep looking
Other reference patterns
Every solution is a worked end-to-end example. If this one is not quite your situation, one of these probably is.
Booking app
Describe the booking flow you want and get a working app — a calendar customers book into and an email confirmation sent on every appointment, all wired up for you.
For anyoneStripe dashboard
Describe the numbers your team cares about and get a private dashboard — revenue, growth and customers — with sign-in, built without touching a line of code.
For anyoneOr the other way of working — connect a repository and get changes as reviewed pull requests:
Add dark mode
Connect your GitHub repo and ask for dark mode. The agent indexes the code, makes the change in a sandbox, verifies it builds, and opens a pull request for you to review.
For developersFix failing tests
Connect your repo and point at the broken test. The agent reproduces the failure, finds the cause, fixes it, re-runs the suite green, and opens a pull request.
For developersJS to TypeScript
Connect your repo and name the components to convert. The agent adds real types, fixes the fallout, verifies the build, and opens a pull request you can review.
For developersBuild bakery website the way it should have been.
Start free. A managed database, authentication and transactional email come wired in, and Go Live puts the app you previewed on a real URL.