Base44 hands you a backend without asking you to configure one, so most apps ship on its defaults. The question worth answering is whether those defaults still fit the way your app is actually being used.
Leave your app URL for a free first check — we run it and email you the result — or read the 41-point checklist we run against every app.
Base44's documentation describes row-level and field-level security — fine-grained authorization rules over who can read which records and which fields. It is a control you configure, not one that configures itself, and the entity nobody got around to configuring is where we find most of what we find.
A rule written as "any logged-in user" holds only as long as logging in is hard. If signup is open, a stranger is one form away from being a logged-in user of your app. We create an ordinary second account and write down everything it can read and change that it has no business touching.
The docs are upfront that schemas are not enforced, so you can change your data model without migrations. That is genuinely useful while you build, and it also means a record can arrive carrying fields your app never planned to store. We check what your write paths let through, and what later reads them back.
It handles the half it can: the database, the auth flows, and the controls you set rules in. Which rules your entities carry is yours to decide, and that decision is what we review.
For the free first check, the app URL. For an audit, read-only access to the Base44 project and, if you have one, a test account with ordinary user rights. We sign an NDA before anything.
It is the cheapest moment. Changing an entity's rules before it holds real customer records costs an afternoon; doing it afterwards means deciding who has to be told.
A free first check, an audit at $690, and a checklist you can compare with anyone else's.
SEE PRICING
