AI App Builder Audits · AI Development Series
UI Bakery App Audit
A different risk profile to the app generators. Your database was already yours — the exposure is in what the tool is now allowed to do to it, and who can make it do that.
Why this one is different
Most tools in this category generate an application and a database from nothing. UI Bakery does not. It is an internal tool builder: it puts a well-made interface on top of data you already have, wherever that data lives. That is a fundamentally different proposition, and it changes what an audit needs to look at.
What a UI Bakery tool is actually made of
- Interface React and TypeScript components, assembled visually and editable in code
- Data sources Your existing Postgres, MySQL or MongoDB, or REST APIs
- Queries SQL and API calls defined inside the platform
- Logic JavaScript actions attached to components and events
- Access Role-based permissions configured in the platform
- Hosting UI Bakery's cloud, or self-hosted on your own infrastructure
Because the database is yours and was presumably designed properly, the entire category of problem that dominates Lovable and Emergent audits — a generated schema that does not fit the business — usually does not apply here. That is a genuine advantage and it is worth saying plainly.
What replaces it is a narrower but sharper set of risks. You have given a tool a live connection to your production database and then let people build things with it. The questions that matter are what those queries do, who is really allowed to run them, and whether anyone could reconstruct the tool if it went away.
What we consistently find
These are the recurring issues in internal tools built on top of a production database, whichever builder was used to make them.
One database login doing the work of everybody
The platform connects to your database using a single set of credentials, and those credentials are typically generous, because restricting them makes things fail while you are building. Every query every user runs arrives at the database wearing that same identity.
The consequence is that your database has no idea who is actually asking. It cannot enforce anything per user, it cannot restrict rows by team or region, and your database audit log shows one account doing everything. All the access control has been moved up into the tool, which is a much thinner place to put it.
What it costs you: your database's own protections are switched off, and you are relying entirely on the layer above.Roles that hide the button but not the query
Role-based permissions in tools like this frequently control what appears on screen. A viewer does not see the delete button, so a viewer cannot delete. That is how it looks, and it is how it is usually tested.
The question we ask is whether the underlying query is still reachable by someone who is logged in and knows it exists. If the permission is enforced only by not rendering a control, then it is a courtesy rather than a boundary. This is the single most common serious finding in internal tools, and it matters more here than almost anywhere else, because internal tools are exactly where the sensitive bulk actions live.
What it costs you: junior staff or a compromised account reaching actions they were never meant to have.Queries assembled by gluing text together
Search boxes, filters and dynamic sorting are the bread and butter of an internal tool, and the quickest way to build them is to paste the user's input straight into the query text. It works immediately, which is exactly why it survives.
It also means somebody typing the right thing into a filter box can change what the query does. Parameterised queries solve this completely and the platform supports them; the issue is that the concatenated version is easier to get working first time. We check every query that takes user input for how it is assembled.
What it costs you: SQL injection, from inside your own admin tool, against your production database.Write access to live data with no undo and no record
Internal tools exist to change things, so they get write permissions, and that is entirely reasonable. What is usually missing is everything around it: no confirmation on destructive actions, no soft deletes, no record of who changed what and when, and no way back if somebody updates two thousand rows because a filter was not applied.
A production database with a friendly interface in front of it is a genuinely useful thing and also a genuinely dangerous one. Most of the damage we have seen from internal tools was done by an authorised person doing something reasonable that turned out to be wrong.
What it costs you: a bad afternoon becomes a restore-from-backup, assuming the backup is good.Business rules scattered across event handlers
Logic in these tools lives in JavaScript attached to individual components — one snippet on a button, another on a table refresh, a third calculating a total. Each is small and sensible on its own.
Collectively it becomes the part nobody can explain. There is no single place to read the rules, no code review, no tests, and typically no version history that tells you why something changed. When the person who built it moves on, the tool becomes something everyone is slightly afraid of, which is a poor state for something the business runs on daily.
What it costs you: a critical tool that only one person understood, and now nobody does.No realistic way to rebuild it elsewhere
This is the one place where the lock-in concern is genuinely fair, and it is worth being straight about. Unlike Lovable, Emergent or Replit, you do not walk away from here with a portable application. The configuration is the tool. The queries and logic can be read and copied out by hand, but there is no export that produces something you could run independently.
That is not a reason to avoid the platform — it is a normal trade-off for this class of product, and the productivity you get in exchange is real. It is a reason to know how much of your operation now depends on it, and to have the queries and rules documented somewhere outside it.
What it costs you: a pricing change, an outage or a policy shift becomes your problem, with no short path out.Where UI Bakery is genuinely good
We think this category of tool is underrated, and UI Bakery is a good example of it. Building an admin panel by hand is dull, expensive work that delivers no competitive advantage whatsoever, and firms routinely spend months of developer time on exactly that. Not doing so is a sound commercial decision.
Genuinely well suited to
- Back-office and admin panels over a database you already own
- Giving non-technical staff safe, structured access to data
- Operational dashboards and reporting for internal use
- Replacing spreadsheets and direct database access, which are worse
- Work that needs doing but does not differentiate your business
Where it needs proper engineering
- Anything customer-facing or reachable from outside your organisation
- Tools that perform bulk or irreversible actions on live data
- Regulated processes that need a defensible audit trail
- Logic complex enough to deserve review, tests and version control
- Anything the business genuinely could not operate without
The honest summary: using UI Bakery for an internal tool is usually the right call. The mistake is treating it as though the ordinary rules stopped applying — because it is internal, because it is only staff, because it was quick to build. It is still software with a live connection to your production database, and it deserves the same scrutiny as anything else that does.
People are careful with the customer-facing app and relaxed about the internal one, when the internal one is the thing with write access to everything. "It is only staff" is not a security model — it is an assumption about people who have already been given the keys.
Prefer to watch? The short version of who we are and how we work
Do you need an audit?
Get it looked at if
- It can write to, or delete from, your production database
- More than a handful of people use it, at different levels
- It touches personal data, payroll, pricing or payments
- You operate under rules that require an audit trail
- The person who built it has left, or is about to
You are probably fine if
- It is read-only and reports on data nobody minds seeing
- One or two trusted people use it
- It is a dashboard, not a tool that changes anything
- Everything it touches is easy to reconstruct if it goes wrong
Questions about auditing a UI Bakery tool
That depends less on who uses it than on what it can do. An internal tool usually has broader database permissions than anything customer-facing, which means the potential damage from a mistake or a compromised staff account is larger, not smaller. If it can only read data that would not matter if it leaked, you are probably fine. If it can change or delete things, the fact that it is internal is a reason to look at it more carefully rather than less.
Usually not. Building admin panels by hand is expensive and does nothing for your competitive position, and we would rather see you spend that budget elsewhere. Most of what we find in internal tools is fixable inside the platform: parameterise the queries, tighten the database user's permissions, move the permission checks somewhere they cannot be bypassed, add an audit trail. We only suggest building something properly when the tool has quietly become business-critical and the platform genuinely cannot support what it now has to do.
Read access to the application in UI Bakery so we can see the queries, the JavaScript actions and the role configuration, plus the database schema and details of the credentials the platform connects with. If you are self-hosted, how it is deployed and network-exposed matters too. We do not need write access to anything and we will not change your tools.
No, and we would rather say so plainly than pretend otherwise. We build with Claude Code and Cursor, with senior developers designing the system, reviewing every change and testing it. What makes us useful here is not UI Bakery expertise, it is that the thing being audited is SQL, a permission model and a production database, which is what we have been working with for years.
It is a fair concern and we will give you a straight answer rather than using it as leverage. You cannot export a UI Bakery tool as a running application, so if you had to leave you would be rebuilding the interface. The practical mitigation is not to avoid the platform, it is to make sure the queries and the business rules are documented outside it, so that what you would be rebuilding is a screen rather than an understanding of how your own processes work. The audit produces that documentation as a side effect.
Built with something else?
We audit what these tools produce, whichever one you used.
Other AI app builders
- Lovable app audit
- Emergent app audit
- Replit app audit
- Bolt app audit
- v0 app audit
- Base44 app audit
- Firebase Studio app audit
- Databutton app audit
- Rork app audit
- a0.dev app audit
- FlutterFlow app audit
- Bubble app audit
- Glide app audit
- Softr app audit
- Adalo app audit
- Retool app audit
- Appsmith app audit
- Budibase app audit
- ToolJet app audit
- Xano app audit
- Airtable app audit
The audit
Find out what your internal tool can really do
The AI Code Audit is £495, fixed.
Tell us what the tool does, who uses it, and whether it can change data. If an audit is not the right thing for you, we will say so.
What the report covers:
- The query layer, including how user input reaches your database
- Whether your permission model is enforced or merely displayed
- What the tool is allowed to do to production data, and what is recorded
- How exposed you would be if you had to move off the platform
We reply within one working day.
