Build your app in the right order: database, payments, admin, pages, languages, SEO

Most apps end up needing the same handful of large pieces: a way to take money, a back office for the owner, a dark mode, other languages, and enough structure that search engines and AI assistants can find and quote them. Each is a day of careful work when done by hand. In AppCrafter each is now a recipe: one press, a few questions, and a detailed request the builder carries out.

Recipes can run in any order. Some orders, though, mean doing the work twice. The Recipes menu now numbers them, marks the ones you have already run, and warns you, without blocking, when one comes before something it depends on.

Before any recipe: the database and GitHub

Connect GitHub right after the first build. It costs nothing, it backs up every version, and it works at any point, so there is no reason to wait. You can create a new private repository or link one you already have.

Connect the database before anything that has to remember who someone is. Payments need to record who paid; the admin panel needs to know who is an admin. Without a database, both can only be demonstrations. With one, the database itself decides who may read what, and the emails of your admins never appear in the app's public code.

1. Payments, then 2. the admin panel

Payments come first because the admin panel has a finance tab. Run it after payments and that tab starts with real income, subscriptions and churn. Run it before and it shows clearly labelled sample figures until payments are connected. Either order works, and each recipe knows about the other, but payments first is cleaner.

The admin panel asks for the owner's email and up to five admin emails before it builds anything. Only people signed in to your app with those addresses can open it, and only the owner can add or remove admins later.

3. The marketing pages

If your product has a marketing site, the next recipe builds its pages: About, Features, Pricing, Help, Docs, Blog and Contact, whichever you pick. It comes after payments so the pricing page shows the real plans, and after the admin panel so contact messages land in its inbox.

4. Email

Email comes next, with the tool you already use: Resend, Brevo, Lumail or Loops to send, and any of those or Kit, MailerLite and SendFox to hold your newsletter list. The keys live as secrets in your own Supabase project. It comes after the admin panel and the marketing pages so the welcome email, the contact form and the newsletter sign-up have somewhere to go.

5. Theme, then 6. languages

Both rework every screen in scope, so run them once your main screens are settled. A screen you add afterwards may need "in both themes" or "in every language" in your request. Each asks whether it applies to the app, the marketing site, or both.

Translating a screen and then redesigning it means translating it twice. Settle the screens, then translate them.

Publish, then 7. SEO and GEO

Search engine work comes after languages, because the sitemap and page tags should list every language. It also comes after publishing, because Google Search Console and Bing Webmaster Tools can only verify a site that is live at its real address. Search engines index the site on your own domain; the free address always stays out of search results. Publish on your domain, get the two verification codes, run the recipe with them, republish, and press Verify.

8. The audit, last

The audit reviews the whole app: security, reliability, performance, accessibility, completeness, search and code quality. It is most useful when there is a whole app to review. It writes a plan rather than changing anything, and the plan appears above the chat with one Implement button per step. Run it before launch, and again after big changes.

Where to read more

The Docs walk through every step, from the first idea to a published app, in this same order. The Features page says what each recipe builds.