Every platform has a gap between what it promises and what it actually does. The gap is usually small and usually undocumented. You find it by walking into it, once per leg.
Base44 is a platform that lets you build full web apps — React frontend, database, auth — from an AI prompt. The pitch is fast: describe the app you want, and it builds it. For rapid internal tools and client-facing dashboards, that's genuinely useful. But the platform has its own physics, and learning them the hard way costs time and money in roughly equal measure. These are the things I wish I'd known at the start.
1.GitHub push is not the same as publishing
Base44 apps are GitHub-connected React/Vite codebases. The natural assumption is: push code to GitHub, changes go live. That is not what happens.
The deploy flow has three steps, not two. First, you push code to GitHub — this syncs it into Base44's copy of the repo. Then you have to call Base44's API to tell it to pull from GitHub and publish the live app. That third step is separate, explicit, and easy to miss. I built it into my workflow after shipping an update, checking the live URL, seeing nothing had changed, and spending twenty minutes wondering why the code looked right but the app looked wrong.
If you're building Base44 apps with Claude, the implication is that you cannot just commit and assume you're done. The publish trigger has to fire.
2.The AI guesses field names — and it guesses confidently
Base44's AI can generate UI and data queries from a prompt. The problem is that when you describe what you want, the AI invents plausible-sounding field names if you don't give it the real ones. It produces code that compiles, runs, and returns nothing — because it's querying engineerName when the actual field is assignedEngineerName, or looking for status "Complete" when the enum is "Completed".
The fix is tedious but reliable: end every Base44 prompt with a technical reference block. Exact entity names (case-sensitive), exact field names, exact enum strings, and the join logic between entities. For a field-service app, that meant listing things like:
Entity: Job
Fields: assignedEngineerName, enRouteLatitude, onSiteMinutes
Enums: "En Route", "Completed", "On Hold"
Relationships: JobPhoto.jobId → Job.idIt adds two minutes to writing the prompt. It saves thirty minutes of debugging why the dashboard renders empty.
3.Everything is public by default — including the personal data
This one matters more than the others.
When you build a Base44 app and don't specify permissions, the platform defaults every entity to fully public: anyone can read, write, and delete any record via the API. The admin interface looks correct — it shows your data, restricts the UI to logged-in users — but the API endpoint underneath is open. Unauthenticated, unrestricted, publicly readable.
I discovered this while building an event companion app where one entity collected contact details: names, email addresses, phone numbers. The admin UI gated it behind login. The API did not. Anyone who knew the endpoint could have pulled the entire list. That's not a UI bug — it's a data exposure waiting to be found.
The fix is to include an explicit permissions table in every Base44 build prompt, before a single entity is created:
| Entity | Create | Read | Update | Delete |
| Lead | public | admin only | admin | admin |
| Vote | public | public | admin | admin |Under GDPR, "I didn't know the defaults" is not a defence. The platform makes it easy to miss this. Write the permissions table before you write anything else.
admin only read permissions in the build prompt. Not as an afterthought — as the first thing you write.4.It charges per message — batch everything
Base44's AI charges per API call. If you build iteratively — small prompt, see the result, small correction, see the result — you pay for every round-trip. On a complicated page that took four rounds to get right, I paid for four messages when one comprehensive prompt would have done it.
The discipline is to collect every requirement before sending anything. Copy, layout, button behaviour, responsiveness, data queries, edge cases — all in one message. Base44 has no memory between calls, so every prompt needs to be self-contained anyway. You're essentially writing a spec. The upside is that writing the spec forces clarity before building, which makes the output better and cheaper simultaneously.
5.Build a mockup before you build the thing
Related to the above: because Base44 charges per edit and builds are slow, reviewing the design and flow in a browser before sending the first prompt saves significant time and money. Build an HTML mockup, look at it, fix what's wrong, get approval, then fire the Base44 prompt. What costs thirty seconds to change in an HTML file costs a full AI message and a rebuild to change in Base44.
I made this a hard rule after shipping a page layout that looked right in my head, landed wrong in the live app, and required two correction cycles to fix. The mockup step would have caught both problems before they cost anything.
The pattern underneath
Every one of these lessons is the same lesson in a different place: Base44 does more than it appears to, makes assumptions you can't see, and charges you for discovering them. The three-step publish flow, the guessed field names, the public-by-default data model — none of it is documented prominently. You find it when something breaks.
The discipline that works is: treat every Base44 build as a spec exercise. Define the exact schema before touching the AI. Specify permissions before defining entities. Write the full brief before spending a message. Build the mockup before writing the brief.
It is not a platform you improvise on. It rewards precision.