Any order still works
The order above is a recommendation. The Recipes menu numbers the steps, marks the ones already run and warns, without blocking, when one runs before what it depends on.
Docs and tutorial
From the first idea to a live app, in order.
Each step builds on the one before it. Follow them in this order and nothing has to be redone. The numbered steps in the builder’s Recipes menu follow the same order.
Before any code
Decide what you are building
- 1
Choose how to start
Right after you sign in
- The start page asks what you want to create today.
- Describe your app: type or dictate it, and drop in any documents about it (Word, RTF, PDF, Markdown, text, images).
- Clone an app: paste the address of a public site or an App Store or Google Play listing, or add screenshots.
- Generate an idea: pick a topic, market and niche, add a few phrases a buyer would search, and get five scored concepts from live research.
- 2
Review the plan
Before the name and the build
- Untick features you do not want, and ask for changes in plain words.
- Use "Answer them all at once" to settle every open question in one go. Blank answers stay open.
- Plans are written in English. If you wrote in another language, one button rewrites the plan in it.
- 3
Name, domain and marketing site
Once the plan is right
- Pick a name with a domain that looks free. "Likely available" means confirm it at a registrar.
- Say whether you need a marketing site next to the app.
- Choose where each goes. By default the site is yourname.com and the app is app.yourname.com.
This choice shapes the first build: with a marketing site you get a landing page and the app; without one the app opens directly.
- 4
Brand studio
After the name
- Compare three directions, each with a logo, an app icon, a banner, colours and a typeface.
- Edit anything, ask for the symbol to be redrawn, then approve one.
- The app is built with what you approve. Download the brand kit whenever you like.
- Started with Clone or Describe and kept your own name? In the builder, Recipes → Brand designs one the same way, or takes your own logo and makes the favicon and sharing image from it. Run it before the pages, theme and SEO, which all use it.
Build
Get a working first version
- 5
The first build
From the builder
- Choose web app or mobile app, pick a model, then build the first version.
- Watch it arrive: files appear in the Code tab as they are written and the preview updates as each is finished.
- A mobile app opens on your phone through Expo Go by scanning the QR code.
- 6
Change it
As often as you like
- Describe a change in the chat. Each message makes a new version, kept in History.
- Press Select, click an element in the preview, then edit its text or describe a change to just that element.
- Restoring an old version adds a copy on top; nothing is deleted.
- 7
Connect GitHub
Right after the first build. It is a backup, and it works at any point.
- Create a private repository, or link one you already have.
- Push new versions, and pull back edits made on GitHub. If both sides changed, you choose which wins.
- 8
Connect the database
Before anything that stores data or needs sign-in
- Database: paste an existing Supabase project's details, or create one in your own Supabase account.
- Review each migration before it runs. Tables anyone on the internet could read or change are refused.
- The Data tab shows what is in your tables and flags anything exposed.
Payments and the admin panel need this: without a database, who paid and who is an admin cannot be stored securely.
Recipes, in order
Add the big pieces
- 9
Recipe 1 · Payments
Once there are users to charge
- Payments (top bar): connect Stripe checkout, or Stripe or PayPal payment links. The money goes to your own account.
- Recipes → Payments builds plans, a pricing page, upgrade buttons, paid access and a billing page. Add your prices in the notes.
Without Stripe connected it still runs, with a clearly marked demo checkout you can switch later.
- 10
Recipe 2 · Admin panel
After payments, so the finance tab shows real income
- Enter the owner's email (yours, as you sign in to the app) and up to five other admin emails.
- With a database, the database enforces who can open the panel and the emails stay out of the app's public code.
- Sign in to your app with that email and confirm it. The panel then appears.
- 11
Recipe 3 · Marketing site pages
After payments and the admin panel, if you have a marketing site
- Tick the pages you want: About, Features, Pricing, Help & support, Docs & tutorial, Blog, Contact.
- For Contact, add the support email to show, and a Formspree form address if you want each message emailed to you (free at formspree.io).
- With a database, messages are saved there and appear in the admin panel's inbox. Review the starter blog posts and draft prices before launch.
- 12
Recipe 4 · Email
After the database, and ideally the admin panel and the contact page
- Choose who sends the app's emails (Resend, Brevo, Lumail or Loops) and, if you have one, the tool that holds your newsletter list (any of those, or Kit, MailerLite, SendFox).
- Paste the keys, the from address on a domain you verified with that provider, and a Supabase access token, then Connect. The keys are stored as secrets in your Supabase project; AppCrafter keeps none of them.
- Then Set up the emails: a welcome email, contact messages emailed to you, a newsletter sign-up form, and an Emails tab in the admin panel.
With Resend, or Brevo plus its SMTP key, sign-up and password emails come from your domain too. Loops sends from templates you publish in Loops, and connects Supabase's emails from its own settings.
- 13
Recipe 5 · Light and dark theme
When your main screens are settled
- Choose the app, the marketing site or both.
- Screens added later may need "in both themes" in your request.
- 14
Recipe 6 · Languages
After the theme, near the end
- Tick any of French, German, Italian, Spanish, Portuguese, Chinese, Russian, Korean and Arabic. English stays the default.
- Choose the app, the marketing site or both.
- With many languages, check each one: a long run can come back incomplete, and a short follow-up message fills the gaps.
Launch
Put it online and make it findable
- 15
Publish, then your domain
When it is ready for people
- Publish puts it on a name.blissfulplan.store address: the marketing site at the address, the app at #/app. Republish to update it.
- On Pro, connect your own domains from the same dialog, one DNS record each: the marketing site on www.yourname.com and the app on app.yourname.com. Either or both; the addresses you chose earlier are filled in.
- With both, the app's address opens straight into the app, and the marketing site's buttons into the app (sign-in included) lead there.
- A bare yourname.com cannot point at the app. Forward it to www.yourname.com at your registrar.
- Search engines index the site on your own domain only; the free address always stays out of search results.
Your own domains go live in a few minutes once the DNS record is in place; the dialog checks by itself.
- 16
Sign-in addresses
With a database, after each new address
- Supabase only signs people in on addresses it knows, and its emails (confirm sign-up, reset password) link to its Site URL.
- In Publish or Database, Sign-in addresses lists every address the app lives at, and says which ones Supabase does not know yet.
- Press Update sign-in addresses with your Supabase access token. It sets the Site URL (the app's own address first) and adds the rest. Entries you made yourself, such as localhost, stay.
Hosted somewhere else too? Add that address there before updating.
- 17
Host it elsewhere (optional)
Any time after connecting GitHub
- Publish → Host it elsewhere has the steps for Vercel, Netlify, Cloudflare Pages and GitHub Pages. Each builds the app from its GitHub copy and updates by itself whenever the builder sends a change to GitHub.
- The settings, if a host asks: build command npm run build, output folder dist. No environment variables are needed.
- For GitHub Pages, add the deploy file the dialog gives you, then set Pages to GitHub Actions in the repository's settings. A private repository needs a paid GitHub plan for Pages.
- Already have a WordPress site? Keep it as the marketing site on www.yourname.com, connect only the App address here, and point WordPress's sign-in buttons at app.yourname.com.
Connect your own domain at whichever host serves it: a domain points at one host at a time.
- 18
Recipe 7 · SEO and GEO
After languages, and after publishing on your own domain
- Get the verification codes from Google Search Console and Bing Webmaster Tools for your live address.
- Run the recipe with the codes. It writes titles, descriptions, structured data, robots.txt, sitemap.xml and llms.txt.
- Republish, then press Verify in Search Console and Bing, and submit the sitemap.
Add languages later? Run this again so each language is listed.
- 19
Recipe 8 · Full audit
Last, before launch, and again after big changes
- The audit reviews security, reliability, performance, accessibility, completeness, SEO and code, and writes a plan.
- The plan appears above the chat. Press Implement on one step at a time, starting with the high-priority ones.
Need to know
Three things worth remembering.
Credits and models
Recipes are big jobs and use about as much as a first build. Economy models go several times further than the most capable ones; the pricing page lists each model.
Your accounts
Code in your GitHub, data in your Supabase, payments in your Stripe. Download everything as a zip at any time, on any plan.
Stuck on a step? The help centre covers the common problems, and the contact form reaches a person.