AI App Builder Audits · AI Development Series
Adalo App Audit
Adalo gets a real app into the stores without code. What the app shows and what its backend will answer are two separate questions.
What Adalo actually hands you
Adalo builds web and native mobile applications with a database included, aimed squarely at people who are not developers. Everything lives on Adalo: there is no code export.
What a Adalo application is made of
- Application Adalo's runtime for web, iOS and Android
- Database Adalo Collections, built in
- Access control Screen and list filters, plus collection permissions
- API A REST API over your collections
- Integrations External collections and API actions
- Hosting Adalo only, no code export
The pattern that matters is the same one that catches people out on every platform of this kind: filtering a list by the logged-in user controls what appears on screen, not what the backend is willing to return.
Adalo exposes a REST API over your collections. If that API is enabled and not properly restricted, the app's screen filters become irrelevant — anyone with the endpoint can ask for records directly.
What we consistently find
These recur in Adalo applications.
Collection permissions wider than the screens
Screens are filtered to the current user, so the app behaves correctly. The collection itself frequently permits far more than the app ever asks for.
Anything that queries the collection directly — the API, another screen, a modified client — gets whatever the collection allows rather than whatever the screen intended.
What it costs you: records reachable outside the interface that was meant to restrict them.Personal data leaving with the app
On mobile, the app is installed on the user's device and its network traffic can be observed. Records fetched for a screen arrive in full, including fields the screen never shows.
Internal notes, other users' contact details and status flags all travel with the records they are attached to.
What it costs you: fields exposed that were never meant to leave the database.Performance falling away as collections grow
Adalo lists fetch and filter in a way that is comfortable at hundreds of records and noticeably slow at tens of thousands. There is limited ability to add indexes or restructure queries.
The app that felt instant during testing becomes the app users complain about, and there is not much you can do inside the platform about it.
What it costs you: an app that gets worse as it gets more successful.Where Adalo is genuinely good
Adalo does something genuinely difficult: it gets a non-developer to a real, installable mobile app with a working database behind it. For a lot of small operational apps that is exactly the right amount of tool.
Genuinely well suited to
- Simple mobile apps built by non-developers
- Internal tools for a small, trusted team
- Directories, booking tools and membership apps
- Proving whether an app idea is worth funding
- Situations where nobody available can write code
Where it needs engineering behind it
- Apps where users must never see each other's records
- Personal data, health data or payment details
- Collections likely to grow into the tens of thousands
- Anything facing a client or investor security review
- Applications you may need to run independently one day
The honest summary: Adalo is a reasonable choice for a small app with modest data, and the two things that will eventually bite are the same two on every closed platform: what the backend permits regardless of the screens, and what you would do if you had to leave.
Prefer to watch? The short version of who we are and how we work
Do you need an audit?
Get it looked at if
- More than one customer or organisation uses it
- It stores personal data of any kind
- The API is enabled and you are not sure what it exposes
- Collections have grown large and the app has slowed
- You are about to promote it, launch it, or raise on it
You are probably fine if
- You are the only person who uses it
- It holds nothing you would mind losing or leaking
- It is a prototype and everyone treats it as one
- Everyone using it could see all the data anyway
Questions about auditing a Adalo build
It depends on your collection permissions, which are set separately from the screens and are frequently wider. Adalo exposes your collections through an API, and that API answers according to the permissions rather than according to what your screens were designed to show.
For internal tools and simple consumer apps it is serviceable. The caution is that the app on the phone and the API behind it are two different surfaces, and only one of them is the one you designed. The API decides what is actually protected.
Where collection permissions allow it, yes, even if no screen ever shows it. The app is a client of your data, not a gate in front of it. Anyone querying the collection directly gets whatever the permissions permit.
Once collection permissions match what you actually intend and you know what the app caches on the device. Personal data leaving with the app is easy to miss, because nothing about the interface suggests it has happened.
Because performance falls away as collections grow. Adalo's database is built for convenience rather than volume, so lists that felt instant while you were building become sluggish once there are real numbers of records behind them.
As a working demonstration, usually yes. Under technical due diligence it is weaker, because there is no codebase for anyone to review and reviewers will ask what leaving would involve. Knowing that answer before the question is asked is worth the hour it takes.
Permission fixes are configuration and quick. Performance problems are usually a symptom of the platform rather than of your build, which makes them harder to fix in place. The audit is £495 + VAT and is honest about which is which. Credited back in full against the work.
It controls what people see in the app, which is not the same as what the backend will return. If the collection permits broader access, or the API is enabled without proper restriction, the filter is doing presentation rather than protection. That gap is the most common serious finding on platforms of this kind.
You would be rebuilding, because there is no code to take with you. Your data can be exported, which is the important part, but the application itself does not come. That is a normal trade for this class of product rather than a criticism — it just means it is worth knowing how much of your operation depends on it before that decision is forced.
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 Adalo expertise, it is that the thing being audited is a data model, a permission scheme and an API.
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
- UI Bakery 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
- Retool app audit
- Appsmith app audit
- Budibase app audit
- ToolJet app audit
- Xano app audit
- Airtable app audit
The audit
Find out what you are sitting on
The AI Code Audit is £495, fixed.
Tell us roughly what you built and how many people use it. If an audit is not the right thing for you, we will say so.
What the report covers:
- Collection permissions, not just what the screens display
- What your API exposes to anyone who calls it directly
- Which fields travel with records that users can legitimately see
- What leaving the platform would realistically involve
We reply within one working day.
