Base44 Prompts: 22 Templates by Build Stage

TL;DR: Base44 prompts carry decisions a chat prompt never does, and they carry them sooner than most app builders, because Base44 generates the database, auth and APIs from your first message. This page follows Base44's own prompting documentation, adds 22 copy-paste templates by build stage, and marks where the tool stops.

Who owns Base44 now, and did anything move?

Wix owns it, the name did not change, and the documentation is where you would expect. Base44's own llms.txt file states that the company was "Founded January 2025 by Maor Shlomo; acquired by Wix June 2025", and the footer of its about page reads "2026 Wix.com Ltd. All rights reserved." The product is still Base44, still at base44.com, still documented at docs.base44.com. Verified 27 August 2026.

That matters practically, because much published Base44 advice predates the acquisition, and the change shows in the product: payments are documented as "Base44 Payments powered by Wix", and buying a domain runs through Wix. If a tutorial mentions neither, treat its other details as equally dated. Two naming quirks give the same signal: the docs now say tables where the older word entity survives in permission rule names and Freeze Files, and the visual editing surface appears as Edit mode, Visual Edits and "Discuss and Visual Edit" on three pages.

Why is a Base44 prompt different from a ChatGPT prompt?

Because it produces infrastructure, not text, and it produces it immediately. Base44's own product description says the platform "generates UI, backend logic, database schemas, authentication, file storage, and APIs automatically." Your first prompt does not sketch a screen. It commits a schema.

That separates Base44 from the frontend-first workflow most app-builder guides teach, including our own Lovable prompt templates, where the advice is to defer the database until data has to survive a refresh. Here there is nothing to defer. Base44's login documentation confirms that "All new Base44 apps come with custom login pages built in", and its permissions page says the same about access rules: "Base44 automatically sets up data permissions as you build your app."

So the question is not when to prompt the data model, but whether you named it or inherited it. Ask for a booking app without naming fields and something still decides whether a booking belongs to a user, what a slot is, and who can read the table. You find out weeks later, from a person who saw a record they should not have.

What does Base44's own prompting guidance say?

It publishes a real prompt guide, better than most of what ranks for this query. Getting-Started/Prompt-guide organises technique into what it calls five moves, and Getting-Started/Prompt-library carries starter prompts by category. Both read in full on 27 August 2026. The framework is Base44's, not ours.

Two lines carry the weight. On vagueness: "Base44 fills in anything you leave out with its best guess, so describe what you want to see on the page." On feedback: "Base44 builds from your target, not from your frustration." The second is the more useful, because the instinct when something looks wrong is to describe the wrongness, which is the one input the builder cannot act on. Base44 also publishes a design recipe worth learning verbatim: "describe 3 things together: what the app does, how it is laid out, and the mood it should have." Every design prompt below uses that shape.

Plan mode, Discuss mode or Default mode: which are you in?

Base44 has two separate places to think before it builds, at two stages, and people confuse them.

Plan mode is the one most guides miss, because it is not in the editor. Base44 describes it as turning "a short conversation into a structured plan you can adjust before Base44 builds anything", with an AI that "asks questions about what you want to build, such as who it is for, what it should do, and what you want to include." Discuss mode is the in-editor equivalent afterwards, and it "uses its own AI model regardless of the model you have selected in your app", which is why its cost stays flat. The rule: anything you cannot state in one sentence starts in Plan or Discuss.

The templates below are ours. The technique underneath them is Base44's, from the pages listed at the end. Everything in quotation marks was read on the page it is attributed to.

Stage 1: how do you write the first Base44 prompt?

Longer than you think, because it is the one prompt where length is free. Base44's quick-start guide states it plainly: "Your first build uses a small, fixed amount, about 1 credit, no matter how detailed your prompt is or which AI model you choose." Every later message is priced by the work it causes.

That inverts the usual advice, so be precise about what it licenses. Base44 still warns that "Packing an entire app into a single prompt makes the result harder to get right and harder to fix when something is off." Both are true: detail costs nothing on prompt one, scope still costs you reviewability. Spend the free detail on what is expensive to change later, the data and the roles, and keep the feature count small.

Build [app name], a [one-line description] for [who uses it].

The one thing they do: [the single key action].
What they see afterwards: [the confirmation or result].

Data to store, with the fields I want:
- [Table]: [field] ([type], required/optional), one per line
- [Table]: [field] ([type], required/optional), one per line

Who can see what:
- [role] can [read/create/update/delete] [which records]
- [role] can [read/create/update/delete] [which records]

Layout: [grid of cards / one long scroll / split screen].
Visual style: [mood in 3-4 words, e.g. calm and professional].
Include empty, loading and error states on every screen.
Build only this. No extra features.

[Your app idea in one sentence.]
Before building anything, ask me the questions you need answered about who
uses this, what they do, what has to be stored, and who is allowed to see
what. Do not generate the app until I have answered.

Turn this into a plan I can review before you build:
[paste your rough description].
Cover the problem, the audience, the core flows, the tables and fields,
the roles and their permissions, and the design direction.
List anything you had to assume because I did not say.

Run the third in Plan mode. The "list anything you had to assume" line is ours, and it is the highest-value sentence here: Base44 is explicit that it fills gaps with its best guess, so asking it to enumerate the guesses converts an invisible decision into a reviewable list.

Stage 2: how do you prompt the data model you actually want?

By naming fields and types, and by asking for the schema before the code. Base44's data documentation describes the model simply: "All of your app's data is organized in tables, just like a spreadsheet." Field types include text, number, boolean, date, file, reference and object, so you can specify them.

Propose the tables for [feature] before writing any code.
For each table: the field names, their types, which are required, and how
they relate to the other tables.
Explain what happens to existing records if I later need to [likely change].
Wait for my approval.

Add [field name] ([type]) to the [table name] table.
Backfill existing records with [value or leave empty].
Update [which screens] to show it, and handle records where it is empty.
Do not change any other table or page.

Review my data model as it stands. For each table, list the fields, the type
of each, and which other tables reference it.
Flag anything that looks like it will cause a problem later: duplicated data,
a missing relationship, or a field doing two jobs.
Report only. Change nothing.

Run all three in Discuss mode. Schema is cheap this week and expensive next month, and Base44's own credit table puts "Large-scale or app-wide change" at roughly 3 to 4 credits, which is what a late schema rewrite becomes.

Stage 3: how do you prompt auth and data permissions?

In plain language, then verify in the dashboard rather than trusting the chat. Base44 encourages the first half itself: "You don't need to configure permissions manually." The half nobody mentions is the rule semantics: "If a person matches any one rule, they get access." Rules combine with OR, not AND. A table with a tight Creator Only rule and a leftover All Users rule is a public table, and it will not look like one in the chat transcript.

Set permissions for [table]: only the person who created a record can read
or update it. Nobody else, including other signed-in users.
After you apply this, list every rule now on the table and tell me plainly
who can create, read, update and delete.

Add roles to this app: [role A] can [permissions], [role B] can
[permissions], [role C] is read-only.
Enforce it on the data itself, not only by hiding menu items.
Then tell me, for each table, which rules would let a [role C] account read
a [role A] record.

Audit access on every table in this app. For each one, list the rules in
place and give me one concrete example of a request that should be blocked.
Report only. Do not change any rules.

One gotcha from the login docs, because it produces a bug report that looks like a Base44 fault and is not: "After you enable a provider, you need to add a button for that provider to your pages." Enabling Google sign-in does not put a Google button on your login screen.

Stage 4: how do you change one screen without wrecking the rest?

Name the target, then stop relying on prose to protect the rest. This is where Base44 diverges most usefully from its competitors: instead of writing "do not touch X" in every message, you can lock it. Its chat documentation describes AI controls with a Freeze Files setting that "Lock specific files or entities so the AI does not modify them", alongside a Custom Instructions field to "Add default guidance for every AI interaction, such as tone, design standards, or preferred behavior."

Set both once, early. A frozen file is a boundary the model cannot talk its way past, which beats a sentence it might weight lightly. It is the structural fix for the behaviour described in why AI rewrites code you did not ask it to touch, rather than the polite one.

Custom instruction, to apply to every message in this app:

Make only the change I ask for. If a request would require editing a file
or table I did not name, stop and tell me which one and why before doing it.
Match the existing typography, spacing and colour palette. Never introduce a
new colour, font or component library.
Always include empty, loading and error states on any screen you build.

Build the [screen name] page.

Sections in order:
1. [section]: [what is in it]
2. [section]: [what is in it]
3. [section]: [what is in it]

Function: [what job this screen does].
Layout: [grid of cards / one long scroll / split screen].
Visual style: [mood in 3-4 words].
States: empty ([what is shown]), loading, error.
Mobile: [what changes].
Only create or edit files for this page.

Design direction for this app, applied to every new section from now on.
Function: [what the app is for].
Layout: [grid of cards / one long scroll / split screen].
Visual style: [mood in 3-4 words, plus 2-3 supporting keywords].
Typography: [feel]. Spacing: [tight / generous]. Motion: [none / subtle].
Do not change any existing screen to match yet. Confirm the direction first.

On [page], change only this: [the exact change].
Keep the layout, typography, colours and spacing exactly as they are.
Do not touch [named neighbouring feature] or the navigation.
If this change needs anything outside [page], stop and tell me first.

The screen and design prompts are Base44's function-layout-style recipe, with the three states bolted on. The last one is deliberately dull, and dullness is the point: Base44's own verdict on "make it better" is that requests like that "give Base44 nothing to work with." A vague instruction is not a small instruction. It is a large one with the scope left blank.

Stage 5: how do you prompt integrations, agents and automations?

Name the trigger, the payload and the failure path, and know that this stage spends a second currency. Base44 bills built-in services in integration credits, separate from the message credits that pay for building, and warns that "There is no way to preview an integration credit cost before running an action."

When [event happens in my app], send [what] to [service].
Trigger: [the exact condition].
Payload: [the fields that matter].
On failure: [retry / log / show the user what].
Store the credentials server-side. Never put a key in code the browser loads.
Tell me what I need to connect before this will work.

Add an automation that [what it does] when [trigger].
List every built-in service it will call on each run, so I can estimate what
one run costs before I turn it on.
Add a guard so it cannot fire more than [n] times per [period].

Add an in-app AI assistant that helps users [do what], using data from
[which tables] and nothing else.
It must refuse anything outside that scope and say so plainly.
It must never reveal records the signed-in user is not allowed to read.
Show me the instructions you gave it.

The rate guard is ours. Base44 documents that an automation calling an LLM and then sending an email costs roughly three credits per run, and that automations chaining several actions "can add up quickly". An unintended loop is a bill, not just a bug.

Stage 6: what do you prompt when the build breaks?

The symptom, the location, the expectation and the actual result, and then the root cause before any fix.

[What is broken] on [which page], when I [exact steps to reproduce].
Expected: [what should happen].
Actual: [what happens instead].
[Paste the error from the Logs page if you have one.]
Find the root cause and explain it before changing any code.

This has survived [n] fix attempts.
List what we have already tried so we do not repeat it, explain in plain
terms why it keeps happening, then propose a different approach that avoids
the problematic area entirely. Do not change code yet.

[Feature] worked [when]. Review the changes made to it since then, identify
which one broke it, and tell me what you found before fixing anything.

Do the second and third in Discuss mode. At 0.3 credits a message, diagnosis is the cheapest thing you can buy here, and blind fixes are among the most expensive.

Two habits from Base44's own guidance close this stage. If a prompt is stuck, its FAQ advises that "If a prompt is not working after a couple of tries, rephrase it and use words like redesign or rebuild", because small edits to a broken thing compound the breakage. And do not assume continuity: the prompt guide lists "Assuming the AI remembers other chats" as a common mistake, so a branch chat or a session picked up days later needs its context restated. If you keep restating the same context, save it, which is the argument in how to reuse prompts without copy-pasting.

Stage 7: what do you prompt before you publish?

Not a prompt at all, for the first item. Base44's security scan "is available on all plans, including the free plan", and "The scan checks for six types of issues": data permission gaps, exposed credentials, login verification gaps, package vulnerabilities, code vulnerabilities and security headers. Run it, then read the results rather than clicking Fix all issues, because the docs flag that the login-verification fix "rejects any caller that has no signed-in user, so it can break a page you show to signed-out visitors, a webhook, or an external integration that calls the function."

Walk me through what a signed-out stranger can reach in this app right now:
which pages load, which tables they can read, and which backend functions
they can call. Report only, in plain English. Change nothing.

List every place this app stores or sends a credential, key or token, and
tell me for each one whether the browser can see it.
Report only.

For [critical flow, e.g. signup, checkout], write the end-to-end test steps
a person would follow, including the ways it could fail: bad input, a
duplicate, a dropped connection, and a signed-out user.
Then tell me which of those the app currently handles.

Where does Base44 stop and real engineering start?

At the line where being wrong costs someone else something, and Base44 says so itself. Its security page is unusually direct for a vendor: "You are responsible for your app's security. The AI chat can help set things up, but always review your settings and run a security scan to make sure everything is configured the way you intended."

Take that at face value. A preview with a handful of records cannot show you a permission rule that combines with OR when you meant AND, a backend function that answers anyone who calls it, or a key the browser can read. Base44 names all three as scan issue classes, which is a more honest signal than any review: the vendor built a scanner because generated apps ship with these gaps routinely. Two further hard edges from its own FAQs: the agent "cannot automatically access or migrate complex backend logic, databases, or private integrations", and "Base44 does not offer refunds or credit reversals for AI actions."

Three areas deserve a human who can read the generated code. Authentication and access rules, because a wrong policy is invisible until it is exploited. Payments, because a checkout that fails after taking money is an incident, not a bug. Personal data, because whatever you store you are responsible for, and the builder is not a party to that obligation.

None of this means non-technical builders should stop. It means the checklist has one extra line: before an app touching logins, money or personal data meets strangers, someone reads the permission rules and the server-side functions. Note too that code vulnerability scanning is documented as Builder-plan-and-above, so on lower tiers part of that net is absent. If you lack that someone, the nearest substitute is asking for a structured review, the technique in how to prompt for a genuinely useful code review.

Does a prompt library actually help with an app builder?

Partly, and it is worth being exact about which part. We make a prompt tool. We do not build apps, we do not generate code, and nothing we ship will audit your access rules. Anyone selling a prompt pack as a substitute for that review is selling you something.

What it genuinely helps with is repetition. Across one project you write the same seven shapes repeatedly: the scoped change with a named boundary, the schema proposal, the permission audit, the bug report, the staged feature, the integration with a failure path, the pre-publish sweep. Those are prompt templates with slots, and retyping them from memory is how the "report only, change nothing" line goes missing on the prompt where it mattered.

The second help is upstream. Bad sessions start with a prompt that names a goal and no constraints, and the cheapest fix is expanding the vague version into the specific one before you send it. Prompt Architects lists Base44 among its supported integrations, described on our integrations page as optimised for Base44's AI app builder and working on base44.com, so your saved prompts sit in that tab. What it cannot do is take responsibility for what your app does with a stranger's password.

The Base44 build-stage checklist

Nine checks, in the order the decisions get expensive.

1. Plan. Use Plan mode before the first build, and edit the plan rather than accepting it.
2. Load the first prompt. Detail is flat-rate exactly once. Spend it on tables, fields and roles.
3. Enumerate the guesses. Ask what it assumed because you did not say.
4. Approve the schema. Propose tables in Discuss mode, approve, then build.
5. Verify permissions. Rules combine with OR. Read the Permissions page, not the transcript.
6. Freeze and instruct. Set Freeze Files and Custom Instructions once, instead of pleading every message.
7. One change per prompt. Boundary named, states requested, every time.
8. Diagnose before fixing. Discuss mode costs 0.3 credits. A wrong fix costs more.
9. Scan and read. Run the security scan, then read the six issue types rather than bulk-fixing them.

Skip one and Base44 makes that decision for you. It usually chooses reasonably. The problem is you will not know which choice it made until something depends on it.

Sources and access date

Every Base44 claim here was read at Base44's own documentation on 27 August 2026, not from a summary. Every page returned HTTP 200 to a plain request and publishes a .md twin, and both base44.com/llms.txt and docs.base44.com/llms.txt exist, so re-verifying is easy and worth doing.

Ownership and product scope came from base44.com/llms.txt and base44.com/about-us. Everything else sits under docs.base44.com:

• Getting-Started/Prompt-guide, Prompt-library, starting-from-your-first-prompt, Quick-start-guide
• Building-your-app/AI-chat-modes, Managing-your-app-data, working-with-branches
• Account-and-billing/Credits, Billing-and-plans
• Setting-up-your-app/Managing-security-settings, running-a-security-scan, Managing-login-and-registration

Credit figures are the claim most likely to age. Base44 marks its own estimates as "subject to change at Base44's discretion", and states that "There is no set credit amount used per message." Treat every number here as read on one day, and check your own credit usage panel for what you actually spent.