All questions, one place

Yes. A meaningful audit requires reading the codebase, not just the running app. We request read-only access to your GitHub or GitLab repository. We never ask for write, admin, or deploy permissions.

We can still run a front-end diagnostic on the live app using browser tools, which surfaces a useful subset of findings (exposed API keys, insecure headers, asset quality). For the full audit (checking for vulnerable software packages, reviewing how logins and access controls work, and assessing overall code quality), we need source code access. If your app was deployed without a repo, we can work with a code export or ZIP. We'll confirm what's possible on the scoping call.

Both. We start with automated scans on the codebase (Snyk for dependency vulnerabilities, SonarQube for code quality), then do a targeted manual review of the core components. We also run a front-end diagnostic against the live app, checking security headers, exposed data in the browser, and asset health. The combination gives a more complete picture than either alone.

Any app with an accessible codebase. We commonly audit apps built with Lovable, Bolt, Cursor, Replit, and Claude Artifacts, deployed via Vercel, Railway, Render, Heroku, or AWS. The underlying stack (React, Next.js, Node.js, Python, Supabase) doesn't change the methodology. If you're unsure whether your setup is in scope, the scoping call is the right place to find out.

Platforms like Bubble and Webflow manage the underlying code for you, which limits what a code audit can surface. For these platforms, a front-end diagnostic (what's visible in the browser) is still useful, but the full deep scan requires an exportable codebase. If you're using a hybrid (no-code frontend with custom backend logic), that's typically in scope. We'll clarify on the scoping call.

Once the report is delivered and the engagement is closed, we revoke our access and don't retain copies of the codebase. The findings report is yours. We don't store, share, or reference your code beyond the engagement.

Every engagement starts with a signed service agreement that includes a confidentiality clause covering all code, findings, and data. Nothing from your audit is shared with third parties. If you have a specific NDA you'd prefer to use, we're happy to review it.

Yes. We're comfortable signing a client-provided NDA as long as it covers the standard terms: read-only scope, confidentiality, no liability for pre-existing vulnerabilities. Send it through before the scoping call and we'll review it ahead of time.

That's the point of the report. Every technical finding is translated into plain English with a clear statement of the business impact: what it means for your users, your data, and your ability to scale. The Production-Readiness Score gives you a single number and letter grade you can explain to a co-founder, investor, or board without needing a developer in the room.

One audit is sufficient to understand your current risk position. It makes sense to re-audit after significant changes, such as a major feature addition, a new developer taking over, or before a scaling event (new enterprise client, fundraising round, marketing push). We'll flag in the report if there are conditions that would warrant a follow-up.

The report gives you documented evidence of your security and code quality posture: the kind of independent technical assessment most investors and enterprise procurement teams ask for. It won't replace a formal SOC 2 or ISO 27001 certification, but for seed-to-Series A due diligence or enterprise vendor onboarding, the Production-Readiness Score and findings report are the kind of evidence that moves things forward. We'd recommend sharing the scope with your investor or procurement contact on the scoping call to confirm it meets their specific requirements, as processes vary.

We flag the technical issues that create compliance risk (exposed personal data, missing access controls, insecure data handling) and note where findings are relevant to GDPR, HIPAA, or PCI-DSS. The audit isn't a formal compliance certification, but it surfaces the gaps that would fail a compliance review and tells you what to fix first.

The audit is diagnostic: we identify and prioritise the issues, we don't patch them. The Fix Roadmap is written so you can hand it to any developer and they'll know exactly what to do and in what order. If you'd like to discuss how the findings could be addressed, that's a conversation for the delivery call.

That's a completely valid outcome. The Fix Roadmap is designed for exactly that: clear priorities, effort estimates, and enough context for your own developer to act on independently. We're happy to answer technical questions that come up as they work through it.

Pre-launch is the best time. Issues are cheaper to fix before users arrive, before data is at risk, and before a security incident could affect your reputation at launch. If you're a week from going live, a Quick Health Check can surface the critical issues that need addressing first without holding up the launch.

Yes, and it's one of the most common cases we see. AI-generated code has specific, predictable failure patterns: hardcoded secrets, missing access controls, dependency bloat, no error handling. We know what to look for because we see these patterns regularly.

Building code and auditing code are different skills. The same way a building inspector catches things a builder wouldn't flag about their own work, an independent audit surfaces risks that familiarity tends to obscure. The report will either confirm it's fine, or show you exactly what isn't.

We'll say so clearly, and the Fix Roadmap will reflect that, distinguishing between issues worth remediating and structural problems where starting again is the more honest recommendation. What you do with that is your decision; you'll have the information to make it.

Investor due diligence is one use case. Equally common: a scaling business that can't afford downtime, a founder preparing to hand the app to a new developer, or someone who simply wants to know what's actually running in their name.