Cases · App check
A client portal built with AI on Firebase, checked and fixed
A sample engagement: the portal and its studios are fictional and hold test data. It was built with Claude Code for this case; every finding and fix is a real run. The fixed portal is live, so you can open it yourself.
Open the portal yourself
Open the live portal →The fixed portal runs on Firebase, with pages on Cloudflare. Sign-ups are closed and no email goes out, so use one of the four demo logins; each lands where that person works. Uploads take images and PDFs up to 2 MB. Everything resets every night, and anyone with these logins sees what others added, so use made-up content.
Demo logins
- Studio owner:
camille@atelierbrume.example/demo-owner - Freelancer on one project:
oskar@bergmotion.example/demo-freelancer - Client's main contact:
jonas@velolumen.example/demo-client - Founder (admin of every studio):
founder@folioport.example/demo-founder
Checked again once it was live
- The live pages match the checked build file for file and carry only the public settings: no private keys, no source maps.
- Signed out, the database, file storage and server functions refuse every read and write, and a missing record looks the same as someone else's.
- A share link gives only its own files; turned-off, expired and suspended studios' links don't open; files are served so they can't run as pages.
- All four roles were tried by hand: signing in, uploads by the studio, a freelancer and a client, and the founder's admin.
Found only on the real Firebase, and fixed: every upload was refused, because the storage rules read more records than Firebase allows; an uploaded file would never have shown up, because the server waited for a second upload event that only the local copy sends; the founder's admin failed for want of a database index; a file a client sent hid behind a filter, so it looked as if the upload hadn't worked. A few low items stay listed for the owner, such as server functions taking requests from any website (they still need the person's sign-in).
Goal
A Firebase app keeps who may read and write what in its access rules, and a portal has many people in it: the studio's owner and team, freelancers on one project, the client's main contact and colleagues, guests with a share link, the founder who runs every studio. The question: in a portal its builder handed over as finished, does each of them see and change only what they should?
Challenge
On the normal path the portal worked: projects, stages, approvals, files and share links behaved, and a signed-out visitor got nothing. The builder's own notes promised that only the client's main contact approves a stage and that every file is checked each time it opens. What was wrong showed only when one person did what only another should: a client's colleague, a freelancer, someone who had just left, a studio that was suspended.
Solution
First the owner's rules were written down: for every person in the portal, what they may see and change in each part of it, with the owner deciding the unclear cases. Then each rule was tried as that person on a local copy with test data, straight against the database, file storage and server functions, not only through the pages. The fixes went back to the builder in plain words, in three rounds, and each round was checked again for what it fixed and what it broke. Then the portal went onto a real Firebase project and was checked there too.
Outcome
29 problems in the portal as delivered: 5 high, 12 medium, 12 low. A client's people could read the notes the studio kept about them; anyone on the studio's side could record a client's approval in the client's name and rewrite past decisions; a file's address kept opening after the person lost access or the studio was suspended; an uploaded HTML or SVG file opened as a page on the portal's own address. After three rounds 26 are fixed and 3 partly; no high is left. The fixes brought 2 high and 6 medium of their own, such as names in Cyrillic or with accents, like Émile, that could no longer sign up; both high and half of the medium are fixed. Left for the owner: 3 medium that take deliberate odd steps, such as a look-alike letter from another alphabet in a name, and some low. 12 more places where the owner later decided differently from what the builder had reasonably done were changed too and are not counted as the builder's mistakes. One portal, built once: the numbers describe this portal, not a rate for such apps.
From the case
The report, 19 pages (PDF)
Service
The same check for your app
You send the code, not your passwords. Every problem comes with an example of who could do what, and every fix is checked again for what it broke.