00 /FRAMEWORK · AUDIT
What a Base44 AI builder audit actually covers.
For founders who built a Base44 app with the AI builder and need to know what it missed before real users arrive: a 12-point checklist (security, RLS, performance, SEO, function timeouts, credit burn, RBAC, webhooks, DNS, Open Graph, sitemap, error monitoring) you can score yourself, or a $497 production audit that returns a written report in one business day.
Short answer
Last reviewed · 2026-09-24
A Base44 AI builder audit is a structured review of an AI-built Base44 app against twelve components: security and Row-Level Security, the auth surface, performance, SEO, function timeouts, credit-burn rate, role-based access control, webhook reliability, DNS, Open Graph metadata, sitemap, and error monitoring. The framework targets the failure modes specific to AI-generated code — orphan policies, missing connecting handlers, untested error paths, prompt regressions — that a generic code review will miss. Each component is checked pass / fail / not-applicable, and the output is a written report with reproduction steps. Apply the checklist yourself by walking each section below, or have a senior engineer run the $497 Base44 production audit, which covers these inside its 12 components and reports in one business day.
01 /THE PROBLEM
Why AI-built is not the same as verified-built.
Base44's AI builder ships features that look complete in the editor but are partially built in the codebase. The page renders, the button clicks, the toast fires — and then the function call lands in a handler that was never wired into a route, or hits an RLS policy the AI forgot to update when it added the new column.
This is the gap an audit fills. The AI does not lie about what it did; it just does not know what it did not do. A code review judges code on style, structure, and idiom. An audit verifies that the code does what the AI claimed it built — that the RLS policies actually match the queries, that the webhook handler is wired into a route, that the type definitions match the runtime schema, that auth context propagates into every function the AI added.
Twelve components, in the rest of this page, define what “checked” means. Each section explains the check, why AI-builder apps fail it specifically, and links to the matching deep-dive remediation guide.
02 /FRAMEWORK
The twelve components of the AI-builder lens.
Each component is a focused check, a known AI-builder failure mode, and a remediation path. Read each one and score your app pass / fail / unknown. This is the AI-builder lens; the productized $497 audit covers these inside its 12 components, listed on the Base44 production audit specification.
Row-level security is the single highest-stakes thing the base44 AI builder will touch and silently get wrong. Every time the AI adds a column, renames a table, or introduces a new tenancy boundary, the existing RLS policies need to follow — and most of the time they do not. The audit enumerates every policy on every table and cross-references it against every read and write the app issues. The common AI-generated failure mode is an orphan policy: a rule pointing at a column that no longer exists, or a table that has no policy at all and is therefore wide open to any authenticated user. The check is not about whether RLS is enabled (the platform tells you that); it is about whether the policies actually constrain what the SDK returns.
AI-generated authentication code passes superficial review and fails on edges. The login page mounts, the OAuth callback redirects, the session cookie is set — and then there is a route the AI added that reads the request without actually validating the token, or a function that runs as the service role because the auth context never propagated into it. The audit traces auth context from the edge to the data layer for every authenticated route, walks the OAuth callback for PKCE and state validation, and tests session expiry behaviour. AI builders are particularly weak at PKCE — the spec is fiddly, the AI ships handlers that decode tokens but do not verify them, and the gap is invisible until somebody mints a token by hand.
TTFB, LCP, INP, and the client-side render path every visitor runs. The AI builder optimises for what compiles, not what is fast. The render path the AI shipped probably round-trips the database three times before painting first content because each component fetches its own slice — the fix is one parent fetch and prop-drilling, but the AI does not refactor in that direction unprompted. Missing indexes are the second silent failure: queries look fine in dev with 200 rows and fall over at 10,000. The audit runs the page against a representative production-shaped dataset and measures actual response times, not synthetic ones. Anything that crosses a 200ms tail at the 95th percentile is flagged with the offending query and the index that would resolve it.
Base44 apps render client-side for visitors, but Base44 serves search engines and AI crawlers a prerendered version of each page — as long as the app's main SEO toggle is on; switched off, crawlers get a bare HTML shell. The audit checks that crawlers actually receive the real headings and content for every public route (not the fallback snapshot or a bare shell), whether pages that use URL parameters have unique titles (Base44 only generates them for pages without parameters), whether per-page meta descriptions are set (Base44 does not write them by default), and whether structured data (Organization, BreadcrumbList, the canonical entity for each page) is present and valid. The most common AI failure here is hallucinated schema — JSON-LD that validates as syntactically correct but references properties that do not exist, which Google silently ignores.
Base44 functions have a hard execution ceiling. The AI builder writes synchronous code that walks a list, calls an external API for each item, and waits — fine for ten items, a guaranteed timeout at five hundred. The audit enumerates every function that does I/O inside a loop, every function that fans out to a third-party service, and every function whose execution time grows linearly with input size. Each gets a projected timeout threshold (the input volume at which the function begins to fail) and a recommended pattern (queue + worker, or batch processing). This is the failure mode users see as 'works for me, breaks for the customer with the big account' — and it is invisible until someone with a real-shaped dataset hits the route.
Every AI prompt costs credits, and the prompt patterns the AI builder ships when it scaffolds your app are not the cheap ones. The audit measures the cached/uncached ratio across the prompts your app issues, projects monthly credit cost at three traffic levels, and flags the prompts that are most aggressively re-evaluating context that could be cached. The AI tends to re-fetch reference data on every request rather than cache it, embed entire JSON blobs in prompts that could be summarised, and call the model for trivial transformations that string functions would handle for free. Credit burn is the kind of bug that looks like a feature until the bill arrives.
RBAC is what RLS becomes when you have more than two roles. The AI builder ships the happy path — owner reads everything, member reads their own — and silently misses the four edge cases between them: invited-but-not-yet-accepted users, suspended users, role transitions mid-session, and admin impersonation. The audit enumerates every role the app supports, every route, and walks each route as each role. The matrix is what surfaces the gaps: a route an unauthenticated user can hit that mutates data; a route a suspended user can still access; an admin route that does not log who took which action. Multi-tenant scoping is checked at the same time — every query either filters by tenant or is flagged.
Webhooks fire whether or not anyone is logged in, and the AI-generated handler typically reads the payload, writes a row, and returns 200. What is missing is idempotency, retries, and the active-user constraint that the platform sometimes silently imposes. Stripe retries a failed delivery for up to three days in live mode (docs.stripe.com, read 23 Sep 2026); an AI handler without idempotency writes a duplicate row each time. The audit verifies signature validation, idempotency keys, dead-letter handling, and (for base44 specifically) the bug-class where webhook handlers only execute when a user is actively in the workspace. Every webhook is exercised against a retry storm and a signature-mismatch attack to confirm the failure mode is graceful rather than silent.
Custom domain, SSL certificate, www / apex routing, MX records for transactional email. The AI builder does not touch DNS, so the typical failure is the team that points an A record at base44 and assumes it is done — and discovers six weeks later that email from no-reply@theirdomain is going to spam because there is no SPF record, the DKIM signature does not validate, and DMARC is unconfigured. The audit checks the live DNS for the deployed domain, validates the SSL chain, confirms www and apex both resolve, and checks the email authentication trio (SPF, DKIM, DMARC) so transactional mail actually arrives. This is the cheapest and most overlooked component of the framework.
Open Graph is what makes a link preview look like a link preview. The AI builder ships a single static og:image inherited from the layout, which means every link to every page on the app — products, articles, dashboards — previews with the same image and the same generic description. The audit checks whether og:title, og:description, and og:image are dynamic per route, whether twitter:card is set, whether the og:image dimensions match the 1200×630 social card spec, and whether link-preview scrapers actually receive the tags. Base44 documents a prerendered version of each page for search engines and AI crawlers; social networks' own preview debuggers are the test for their scrapers, and a tag injected by client-side JavaScript after load is the one to catch.
Base44 generates /sitemap.xml and robots.txt for you, and a per-page indexing toggle in Advanced Settings removes a page from the sitemap and adds noindex; pages that require a login are always excluded (docs.base44.com, read 23 Sep 2026). The failure is configuration, not a missing file: a public page switched off by mistake, a landing page that sits behind a login, or the app's main SEO toggle turned off, which also disables prerendering. The audit walks the sitemap, confirms every URL resolves to a 200, cross-references it against the app's actual public route table, and flags every public route that is missing from the sitemap or carries noindex.
If you cannot see errors, you cannot fix them. The AI builder rarely wires Sentry, Datadog, or any external observability — it relies on base44's own runtime error view, which captures the obvious crashes and misses the silent ones. The audit checks whether errors thrown inside try-catch blocks are forwarded to a monitoring service or swallowed, whether front-end errors (the kind that produce a white screen for one customer and nobody else) are captured, and whether request-correlation IDs flow from edge to function to database query. The most common AI failure is the catch block that returns a default value and never reports the underlying error — the UI shows success, the database is empty, and there is no log line anywhere.
The productized audit runs these inside its own specification: 12 components, 110 individual pass/fail checks, approximately 340 minutes of scoped engineer time. The same specification is applied to every audit, so reports are comparable across apps and across snapshots of the same app over time.
03 /SELF-SCORE
Score your own app against the twelve components.
The framework is published so any team can apply it. Walk the twelve components in order, score each one pass / fail / unknown, and budget two to four hours per component for an honest pass.
A./STEP
Walk each component in order
Read the component explainer above and the linked deep-dive remediation guide. For each one, write down whether your app passes, fails, or you do not yet know.
B./STEP
Reproduce every fail
A finding without a reproduction recipe is a guess. For every component you marked fail, write the exact steps that surface the bug. If you cannot reproduce, downgrade to unknown.
C./STEP
Decide: self-fix or outsource
Three or fewer unknowns and zero fails on security and auth? You probably do not need an outsourced audit. More than that? Read your result in the table below.
| Your result | What it means | Next step |
|---|---|---|
| Zero fails on security and auth, three or fewer unknowns | The AI builder’s highest-stakes gaps are closed. | Fix any remaining fails yourself with the linked playbooks. |
| Any fail on Security & RLS or Auth surface | Data or accounts can be reached by the wrong user. | Fix it before launch: a $1,500 Base44 fix sprint covers one high-impact issue. |
| More than three unknowns | You cannot yet see enough of the app to decide. | Order the $497 production audit for a written diagnosis. |
The $497 fee is credited in full against any fix, build, migration or written-recommendation engagement booked within 30 days. If you ordered the audit for a specific bug and we cannot reproduce it, we refund the fee; otherwise it is non-refundable.
04 /PROVENANCE
About the framework.
Base44Devs assembled the twelve-point checklist from the OWASP top ten, the Wiz (July 2025) and Imperva (August 2025) disclosures, and the failures that kept surfacing in our own Base44 fix work as “the AI did not know it had to do this”: function timeouts, credit-burn projection, webhook idempotency under retry storms, RLS drift after AI edits, and SEO settings left off. Base44 serves search engines and AI crawlers a prerendered version of each page, so when a Base44 app still does not show in Google the cause is usually configuration: the SEO toggle switched off (which disables prerendering), missing per-page meta descriptions, pages behind login or set to noindex, or simply a new domain Google has not crawled yet.
Every component is grounded in a real failure observed in a real app, not in a theoretical threat model. The framework is published in full because publishing it is what makes it auditable — anyone can apply it, anyone can argue with it, anyone can extend it. The version on this page is rev. 2026-09. Read about the team that built the framework.
If you want a senior engineer to run the full specification against your app and ship a written report inside one business day, that is the productized Base44 audit at a fixed $497. The $497 fee is credited in full against any fix, build, migration or written-recommendation engagement booked within 30 days. If you ordered the audit for a specific bug and we cannot reproduce it, we refund the fee; otherwise it is non-refundable.
05 /FAQ
Frequently asked questions
Q.01What should an AI-built app audit check?
Twelve components, through the AI-builder lens: security and RLS, the auth surface, performance, SEO and schema, function timeouts, credit-burn rate, RBAC and multi-tenant scoping, webhook reliability, DNS, Open Graph, sitemap and robots.txt, and error monitoring. Each is a place where AI-generated code looks finished in the editor and fails in production. Every finding needs a severity and reproduction steps, so the report reads as a fix list rather than an opinion. The productized $497 audit covers these inside its 12 components, the 110-check Base44 production audit specification.
Q.02Does Base44's Security Scan catch AI-builder mistakes?
It is the right first step, not the whole audit. Base44's Security Scan is available on every plan, including Free, and checks seven types of issue: data permission issues, exposed secrets, unauthenticated backend functions, credit protection, app dependencies, code vulnerabilities (Builder plan and above) and security header recommendations (Base44 docs, read 23 Sep 2026). Base44's own launch post (16 June 2026) says: 'Security Scan is not promising your app is secure.' The scan does not walk each role through each route, replay webhooks under retries, time functions at production volume, or check DNS, Open Graph and sitemap configuration. Run the scan first, then score the rest of this checklist.
Q.03How much does a Base44 audit cost?
The Base44Devs production audit is a fixed $497. A senior engineer applies the 12-component, 110-check specification to your app and delivers a written report, with a severity and reproduction steps for every finding, one business day after access (two for 15+ tables or multiple integrations), plus a 30-minute walkthrough. The $497 fee is credited in full against any fix, build, migration or written-recommendation engagement booked within 30 days. If you ordered the audit for a specific bug and we cannot reproduce it, we refund the fee; otherwise it is non-refundable. Order the $497 audit.
Q.04Why do AI-generated apps need a different audit than hand-written ones?
Because AI-generated code fails in a different shape. Hand-written code typically fails on the parts the engineer thought hardest about — the AI fails on the parts it did not realise were connected. RLS policies that did not get updated when a column was renamed, webhook handlers that were generated without idempotency, OAuth callbacks that decode tokens but do not verify them. The audit framework is designed to catch the integrity gaps the AI does not flag, not the style issues a code review would.
Q.05Can I score my own app against this checklist without buying an audit?
Yes — that is what this page is for. Walk the 12 components, read the matching fix playbook for each one, and score your app pass / fail / unknown on every line. If you finish with three or fewer 'unknown' verdicts and zero 'fail' on the security and auth components, you probably do not need an outsourced audit. If you finish with more, the $497 production audit applies the full specification to your app in one business day.
Q.06How long does the checklist take to apply yourself?
Budget two to four hours per component for an honest pass on your own app, more if any of them surface issues that need investigation. The productized audit ships in one business day because its specification is rehearsed and the tooling is preloaded: its 110 checks take about 340 minutes of scoped senior-engineer time.
Q.07How is this different from a generic security audit?
A generic security audit assumes a hand-written codebase and looks for the OWASP top ten. The base44-specific framework looks for the AI-builder failure modes — RLS drift after schema edits, webhook handlers without idempotency, function timeouts on operations the AI scaffolded for ten items, credit-burn from prompts that should have been cached. Security and RLS is one of the twelve components, but the other eleven are platform-specific and AI-generation-specific. A generic auditor will miss most of them.
Q.08Where did the 12-point checklist come from?
Base44Devs assembled it from the OWASP top ten, the Wiz (July 2025) and Imperva (August 2025) disclosures, and the failures that kept surfacing in our own Base44 fix work as 'the AI did not know it had to do this': function timeouts, credit burn, webhook idempotency, RLS drift after AI edits, and SEO settings left off. It is published in full so anyone can apply it, argue with it or extend it.
06 /NEXT STEP
Want us to run this on your app?
A senior engineer runs the full 12-component, 110-check specification and delivers a written report one business day after access. $497 fixed. The $497 fee is credited in full against any fix, build, migration or written-recommendation engagement booked within 30 days. If you ordered the audit for a specific bug and we cannot reproduce it, we refund the fee; otherwise it is non-refundable.