Users should only see their own records
The screens hide other accounts, but you need to check that the API and database enforce the same rule.
Explore
AI-native development · Security for vibe-coded apps
Your app runs. Who can see the data?
You built an app with Lovable, Cursor or Claude Code. Now real users are about to arrive, or a business customer sent a security questionnaire. We check access controls, exposed keys and the paths to sensitive data, then fix the issues you approve. You get a written report and verified changes in your repo.
- 130+People, remote across Poland
- 44 daysFirst line of code to live, one consumer product
- 5.0Clutch rating, 11 reviews
This is for you if the app is about to meet people who did not build it
A customer sent a security questionnaire
A deal depends on knowing what the app actually does. You need evidence for the questions it can answer and a clear list of gaps.
A key may have shipped to the browser
You need to know what it can access and which credentials need to change, with the effect on the app checked first.
You want to keep the work that holds up
The app already has useful screens and flows. You need a reasoned fix plan before approving a rebuild.
What you get. A reviewed path to safer use
An access and exposure report
What we checked, the evidence for each finding and what was outside the review. Permissions, exposed credentials and data paths are tied to the affected parts of your app.
A keep, fix or replace plan
Keep useful screens and flows where the review supports them. Replace weak access checks and exposed credentials. Each proposed change has a reason and an estimate.
Fixes checked against user roles
Approved changes in your repo, with tests for the affected behavior. You keep the report, code and verification results for your team or the next developer.
Software and architecture prepared for review
We analyze gaps against the technical requirements relevant to your SOC 2, ISO 27001, GDPR or HIPAA work, then adapt the software and architecture within an agreed scope. You receive implemented controls and evidence for audit or compliance review. We prepare the system; we do not issue certifications or guarantee compliance.
What we check first
Authentication and authorization
Who can read and write what, enforced in the database and the API, not only in the screens. Row-level security that holds outside the happy path.
Secrets and keys
What shipped to the browser or the repo history, what each key can do, and a rotation plan that does not take the app down.
Public surface
Data APIs exposed by default, admin routes, file storage, test environments with real data, headers and CORS.
Tenant isolation and roles
One company cannot see another's records; team roles, admin tools and white-label setups built on that boundary.
Dependencies and the pipeline
Known vulnerabilities, secret scanning, who can merge and deploy, and whether a change can reach production unread.
A written report you can act on
What we checked, what we found, what we fixed and how we verified it, and which items in your customer's questionnaire the review does not cover.
No rewrite by default
What stays and what goes
We review what you have, then explain what can stay, what needs fixing and what needs replacing. You get the list before agreeing to paid work.
What usually stays
Your auth provider: Supabase Auth, Clerk, Auth0, Firebase
The screens and flows users know
Your data, with access rules added around it
Your user accounts, with sessions reset where security requires it
What usually goes
Permissions enforced only in the frontend
Service-role keys in client code
Policies that return true for every logged-in user
Test environments with real customer data
Tech stack. Security tools backed by manual review
OWASP Top 10 and API Security Top 10 guide risk coverage; OWASP ASVS helps define the checks for the agreed scope. We combine static analysis, dependency and secret scanning, and OWASP ZAP with manual review of authorization, data flows and infrastructure. Tool output is checked against how your app actually works.
Tech stack
- OWASP Top 10
- OWASP ASVS
- OWASP API Security Top 10
- OWASP ZAP
- Semgrep
- CodeQL
- Snyk
- Trivy
- Gitleaks
- Dependabot
- Supabase RLS
- Supabase Auth
- Auth0
- Clerk
- Firebase Authentication
- Cloudflare
- AWS IAM
- Microsoft Entra ID
- Google Cloud IAM
- Sentry
How we work
Inspect before replacing code
Our engineers have built software for banks, fintechs and enterprise systems where security is not optional, including investigative software for Polish financial-crime authorities through Matic, AML software for political advertising spend in the US, and the SignalMesh crypto platform. These projects inform how we review sensitive data, access control and enterprise architecture. We trace requests through your app, agree the scope and document the evidence before proposing changes. The limited first review helps scope the work; it does not replace a full audit.
Their ability to quickly deliver high-quality solutions while maintaining transparency in communication is rare.
How it works. From a running app to checked fixes in your repo
Within one business day: agree the review
We reply, ask for read access to the repo (or an export) and a test account for each role, and agree which paths the review covers and which it leaves out. NDA first if you want one.
Free written review: see what is exposed
Permissions, keys that shipped to the browser, public data APIs and admin routes: what is exposed, how serious it is and what we would fix first. Limited scope, typically within a few business days of getting access.
Fixed-scope, fixed-price fixes: approve the tests
The fixes as a paid engagement, with a test for each role (a customer cannot read another customer's rows) that you approve before we start.
Report and fixes in your repo
What we checked, what we found, what we fixed and how we verified it, plus the questionnaire items the review does not cover. It is an engineering review, not a penetration test or a certification.
Proof, not promises
AI · FinTech
Taking over a crypto platform no one else could ship
Security · Government
Financial-crime investigation software for Poland's authorities
Questions about hardening an AI-built app
- No. We work in your repository, your cloud and the tools your team already uses. If one of them gets in the way of the work, we tell you what and why, and you decide.
- With a 30-minute scoping call. We look at what you have and what you need, then propose a first step with its scope and price before any work starts.
- A limited first review to scope the work is free. The hardening work is a paid engagement with a fixed scope and price. We agree what the report and fixes cover before implementation.
- The limited first review is typically ready within a few business days of receiving access. The fix schedule depends on the findings and is agreed before implementation. That first-review timing does not cover a full audit or all repairs.
- We start with what you have. The written plan identifies what can stay and gives a reason for each replacement. Useful screens, flows and data do not need to be discarded because AI helped build them.
- The anon key is public by design; the question is what the policies let it do. A service-role key in the browser is a leak. The review tells you which case you are in and what to rotate.
- We agree testing boundaries around the users and data already in use. Permission changes are checked on a staging copy before release. The rollout plan covers any effect on existing workflows.
- This service covers a scoped engineering review and hardening work. We can also analyze gaps and adapt the software and architecture to support preparation for SOC 2, ISO 27001, GDPR or HIPAA review. That work is scoped separately from the limited first review. We provide technical changes and evidence, not certification or a guarantee of compliance. Organizational processes and any independent assessment remain separate responsibilities.
- Where our review covers a question, the report provides the findings and evidence. It also identifies questions outside the scope. Your company remains responsible for the statements it sends to the customer.
- The report, approved fixes and verification results stay with you in your repo and project records. Your own team or another engineer can use them for later changes.
- At Signal Mesh, any authenticated user could read or delete all data in the inherited database. Before launch, we restricted database access, secured the API and limited users to their own records. We have made the same mistake ourselves: an app we built in 20 hours went live with row-level security off and a publishable key in the repo. We locked 22 tables, revoked anonymous access and killed 109 sessions in one transaction.
How we think about this, in our own words
Interactive briefs and articles by our team, picked for this service
The new Pareto: 95/5
Why the part of an AI-built app nobody shows (permissions, edge cases and failures) is where the remaining effort and the risk sit.
Read the briefPirxey World: our second brain, with the access we already had
How we built our own AI assistant around the access people already had, with personal logins and separate repositories.
Read the briefAgentic Development vs. Vibe Coding
Vibe coding and agentic development split risk and responsibility differently; this helps you judge which one your app's data can afford.
Read the articleShow us the app you are preparing to open up
Tell us how the app was built, who uses it and what a customer needs checked. Include the decision deadline so we can scope the review.
Direct contact
Mike KacprowiczBook a callChief Growth Officer