Base44 is an AI app builder that generates real TypeScript apps with managed backends. You describe an app in natural language, the platform generates the code, and it hosts it for you. The marketing pitches it as "build apps in minutes." The honest version is that you can build a working prototype in a day, and a production-ready version of that same prototype in two to four weeks — the rest is hardening, debugging, and learning the platform's quirks. This guide, written by the lead engineer at Base44Devs, is the version we wish we had when we started: what base44 actually is, the five-step workflow that ships, and the eight gotchas every new user hits in the first two weeks.
Base44 is an AI app builder that turns natural-language prompts into full-stack TypeScript apps with managed databases, backend functions, and authentication. To build a real app, plan the data model before prompting, generate a v0 with the agent and iterate, verify auth and row-level security as the first production gate, wire integrations like Stripe and webhooks deliberately, and run a pre-deploy checklist before publish. Most new users hit eight specific gotchas in the first two weeks: credit burn on minor edits, AI agent regressions, RLS desync after edits, function timeouts, the post-login white screen, prompt conflicts that produce contradictory code, stale cache after deploys, and hallucinated entity fields. Each is fixable; none are obvious from the marketing.
What base44 actually is (and isn't)
Base44 is a prompt-driven code generator with managed hosting. You write what you want in English; the agent emits a React + TypeScript frontend, a managed entity database, Deno backend functions, and a built-in auth system. Everything it generates is real code. You can read it, edit it directly in the IDE, and export it on Pro tier and above.
This puts base44 in the same category as Lovable, Bolt, and Replit Agent, and a different category from Bubble, Glide, or Webflow. The latter group hides code behind a visual layer; base44 surfaces it. That difference matters because the failure modes are different. No-code platforms fail when you hit a feature ceiling. Code-generation platforms fail when the agent generates code with subtle bugs you have to debug like any other codebase.
What base44 is good at: greenfield generation, CRUD-heavy apps, internal tools, B2B SaaS under five thousand monthly active users, and prototyping anything you can describe in a few paragraphs. What it is not good at: high-traffic consumer apps, native mobile, real-time collaboration, and regulated workloads. The full list of structural limits lives in base44 limitations explained.
The platform charges in two dimensions: a monthly subscription (Free / Starter / Pro / Enterprise) and credits, which are consumed by AI agent prompts and certain platform operations. Credits do not roll over. The credit line is what surprises most teams; the realistic numbers are in base44 pricing real costs analysis, and you can model your own usage with our cost calculator.
The five-step workflow that actually ships
There is a workflow that produces production apps on base44 and a workflow that produces stalled prototypes. The difference is mechanical. Here is the workflow we use on every client engagement.
Step 1 — Plan the data model BEFORE prompting
This is the single most important step and the one most new users skip. The agent will happily generate a data model from your prompt, and the model it generates will be wrong in ways that are expensive to fix later.
In our last thirty client engagements, twenty-six of them had at least one entity-schema mistake that required rework after launch — wrong primary keys, denormalized fields that should have been references, missing tenant_id columns on multi-tenant apps, integer fields that should have been strings.
Before opening the IDE, write down on paper:
- Every entity (table) the app needs.
- Every field on each entity, with its type.
- Every relationship between entities.
- The ownership rule for each entity (who can read, who can write).
- The tenant_id field on every entity if you are building multi-tenant.
Then prompt the agent with the schema as a hard constraint: "Create the following entities with exactly these fields and relationships. Do not invent additional fields." The agent is much better at executing a specified schema than at designing one.
Step 2 — Prompt for v0, then iterate
With the schema fixed, prompt the agent for the rest of the app in scoped chunks. Two prompting rules that matter more than any others:
Scope every prompt narrowly. Name the file, name the function, name the lines, and explicitly forbid changes elsewhere. A loose prompt like "add a logout button" can rewrite the entire Header.tsx and burn five to fifteen credits. The same change, scoped tightly, is one to three credits. The credit-burn math is in our credit-system explainer.
Snapshot before every agent turn. The platform's snapshot feature is free and lets you revert any turn that produces a regression. Use it every single time. The teams that do not snapshot end up in the regression loop we cover at the AI agent regression loop fix — three turns deep, the original change is still broken, and they have burned eighty credits trying to fix it.
The agent is excellent at greenfield generation and inefficient at iterating on existing code. For small edits to stable code, the in-IDE code editor is faster and cheaper than the agent.
Step 3 — Test the auth + RLS as the FIRST production gate
Before you wire integrations, before you build features two and three, before anything else: verify that your row-level security actually works. This is the single most common cause of data-leak incidents we audit.
Two specific failure modes to test for:
SSO bypass on email/password endpoints. If you enable Google SSO, the platform may still accept email/password logins to the same accounts unless you explicitly disable that path. We documented the exact reproduction at the auth bypass fix. Test it with a second account before you ship.
RLS rules out of sync after AI edits. Every time the agent edits an entity schema, the row-level security rules can silently fall out of sync with the new field structure. New fields default to permissive. A field added by the agent on Tuesday can leak data on Wednesday. The reproduction and the audit script are at the RLS desync fix.
The test pattern: create two real test users in different tenants, log in as user A, attempt to read every entity, then check whether user B's records appear. Do this on every entity, every time the schema changes. Five minutes of manual testing in week one prevents a six-figure incident in month six.
Step 4 — Wire integrations (Stripe, webhooks) carefully
Once auth is solid, wire your external integrations. The two that catch new users hardest are Stripe and webhooks.
For payments, use Stripe Elements (not the full Checkout redirect) and keep card data outside base44's stack. This keeps you at PCI SAQ A, which the platform can handle. Anything beyond SAQ A requires controls the platform does not support. The full setup walkthrough lives in the Stripe integration guide.
For webhooks, the gotcha is that base44's scheduled functions and webhook handlers have been documented as unreliable when no users are actively using the app. Time-sensitive webhooks (subscription renewals, payment retries, daily reports) need an external trigger — cron-job.org, GitHub Actions, or your own scheduler — calling into a base44 backend function. The full pattern with idempotency keys and signature verification is in the webhooks complete guide.
Step 5 — Pre-deploy checklist before publish
Before pressing publish, run through a fixed checklist. Skipping this is how prototypes ship as production apps and incidents follow.
The minimum gates: row-level security audit on every entity, rate limiting on AI-triggering endpoints, error monitoring wired to a real channel (not the platform's default), backup procedure documented and tested, custom domain configured with TLS, and a documented rollback plan. The full checklist with command-by-command verification steps is at the deployment checklist.
The teams that run the checklist ship cleanly. The teams that skip it ship and then spend the first week firefighting issues the checklist would have caught.
The eight gotchas every new user hits
Across our client engagements, the same eight issues come up in the first two weeks for almost every new user. Here is the short version with pointers to the deeper write-ups.
1. Credit burn on minor edits
Asking the agent to "change the button color" can rewrite an entire two-hundred-line component file and burn five to fifteen credits. The cost is decoupled from the change's value. In our last thirty engagements, twenty-two hit this in week one. The fix is scoping prompts narrowly and using the in-IDE editor for small changes. Full pattern at the excessive credit burn fix.
2. AI agent regression loop
The agent introduces a regression on prompt N. You ask it to fix on prompt N+1. The fix introduces a different regression. Three turns later you have burned eighty credits and the original change is still broken. The structural fix — snapshot, revert, never re-fix — is at the regression loop fix.
3. RLS desync after AI edits
The agent edits an entity schema and the row-level security rules silently fall out of sync. New fields default to permissive read access. We have walked into post-mortems where a single AI edit exposed every customer's data for nine days. The audit script is at the RLS desync fix we documented.
4. Function timeout
Backend functions have an execution ceiling (around thirty seconds on most tiers). Long loops, large list-then-process patterns, and synchronous calls to slow third-party APIs hit the ceiling and fail silently. The fix is to chunk the work, paginate the lists, and move long-running jobs to an external scheduler.
5. Post-login white screen (the 405 race)
A specific failure mode where, after login, the app renders a white screen and the network tab shows a 405 on the auth callback. It is a race condition between the platform's auth handshake and the React app's mount. The full reproduction and the one-line fix is at base44 white screen 405 after login.
6. Prompt-conflict contradictory code
Two prompts later in the conversation contradicted an earlier prompt; the agent generated code that satisfies neither cleanly. Symptoms: features that half-work, conditionals that never fire, two functions that do nearly the same thing. The fix is to read the diff every turn and reject any turn that adds code conflicting with intent.
7. Stale cache after deploy
You publish a new version, but users continue to see the old version for minutes or hours. The platform's CDN caching is aggressive and not always invalidated on publish. The fix is a manual cache-purge step in the deploy checklist and a version string in the app shell that surfaces which build is live.
8. Hallucinated entity fields
The agent generates code that references user.organization_id when the actual field is user.org_id, or invents a field that does not exist on the entity. The code looks reasonable, the build passes (TypeScript types on entities are loose), and the bug only surfaces at runtime. The fix is to read the entity schema in the IDE and reject any agent-generated code that references fields not actually on the entity.
The pattern across all eight: the agent will produce plausible-looking code that has subtle wrongness. The job of the human is to read the diff, run the verification, and never trust the agent's claim that "I have fixed the issue." Verify everything.
What this guide doesn't cover
This is a getting-started guide. It explicitly does not cover:
Scaling beyond ~5,000 monthly active users. The platform tops out around there before performance and credit costs make the economics unworkable. If you are heading past that ceiling, the migration playbooks live at the migration index.
Native mobile. The platform produces React web apps. There is no first-class native build path; web-view wrappers run into Apple's StoreKit requirements for digital purchases. If you need native, plan to migrate the frontend.
Multi-tenant SaaS architecture beyond the basics. Real multi-tenant SaaS — with tenant isolation, billing per tenant, role-based access across organizations — is doable on base44 but takes deliberate engineering. The platform has no native tenant primitive; you build it on top. We cover the patterns in the solutions hub by vertical.
Performance and credit-burn optimization for established apps. If your app is already running and you want a structured pass to find the savings, that is what our audit is for. The cost is $497 and we typically find 50–70% credit reduction and a list of security gaps to close.
Specific bug fixes. The fix index catalogues every issue we have seen with reproductions and one-page resolutions.
What to read next
Pick by your situation:
- You are evaluating base44 for a specific app: is base44 production ready is the decision framework.
- You want to know what the platform can't do: base44 limitations explained is the structural-gaps reference.
- You are about to ship: the deployment checklist is the pre-publish gate.
- Your credit bill surprised you: base44 credit system explained is the working model and optimization patterns.
- You are wiring payments: the Stripe integration guide.
- You are wiring time-sensitive jobs: the webhooks complete guide.
- You are comparing base44 against Lovable, Bolt, or Replit: the compare hub.
- Your app is already on base44 and you want a second opinion: the audit is $497 and produces a written report.
Closing
Base44 is a useful platform. It is not a magic platform. The teams that ship on it treat it like any other engineering stack: read the diffs, verify the auth, plan the schema before prompting, run the pre-deploy checklist, and never trust the agent's self-assessment. The teams that treat it as a no-code shortcut hit the eight gotchas above, often all of them, in the first two weeks.
If you want help skipping the trial-and-error phase, we audit base44 apps for $497 and produce a written report with a prioritized fix list. We also run fix sprints for specific issues and migrate apps off the platform when the fit is wrong. The honest version of "should I use base44?" is "for what, and with what hardening?" — and that is the question this site exists to help answer.