Where I help
I look at your app the way real users, real attackers and real regulators eventually will, then help you put right what matters. I weigh every area against what you’re building and how close you are to launch.
Security
The gaps attackers look for, from logins to access control.
Authentication and sessions
How people log in and how sessions are handled, including password storage, session expiry and secure cookies. Weak login handling is one of the most common ways AI-built apps get compromised.
Access control
Whether people can only see and do what they’re meant to. AI tools tend to build the main path well but miss the guards that stop one user reaching another’s data.
Secrets and API keys
API keys, database passwords and tokens that have ended up in the code or exposed to the browser. A leaked key can run up a large bill or expose your data before you notice.
Input handling and injection
How user input flows through the app, and whether common flaws like SQL injection and cross-site scripting could be used to read your database or take over accounts.
Dependency vulnerabilities
Third-party packages with known security issues, since generated projects often end up pinned to old or vulnerable versions.
Rate limiting and abuse
Whether key actions can be hammered or abused, such as brute-forced logins, spammed forms or costly requests run in a loop. Throttling is rarely there by default.
Privacy and data protection
GDPR basics: lawful data use, encryption and honouring requests.
Lawful basis and consent
Whether you have a clear, lawful reason for collecting personal data and, where you need it, proper consent, including a cookie banner that actually does what it claims.
How much data you hold
What personal data you store, and whether you really need all of it. Holding less lowers both your risk and your obligations.
Storage and encryption
Whether personal data is encrypted in transit and sensitive fields are protected where they’re stored, rather than sitting in plain text.
Where data goes
Where your users’ data travels, including analytics, email tools and AI APIs, and whether that’s disclosed. Sending data to an AI API in particular has real implications under GDPR.
Privacy policy and records
Whether your privacy policy matches what the app actually does with data, and anywhere the two don’t line up.
Deletion and data requests
Whether you can find, export and delete a person’s data when they ask. It’s a legal requirement that’s easy to miss until the first request lands.
Reliability and error handling
What happens when things go wrong, from errors to backups.
Error handling
How failures are handled, rather than the app crashing or showing raw errors to users. Generated code often assumes everything works first time.
Logging and visibility
Whether you can see what’s happening in production, so when something goes wrong you can diagnose it rather than guess.
Coping when things fail
What happens when a third-party service or the database is unavailable. A sturdy app carries on in a reduced way instead of falling over completely.
Backups and recovery
Whether your data is backed up and a restore would actually work. Plenty of apps launch with no real backup until the first bad day.
Data integrity
The race conditions and validation gaps that quietly let bad or duplicate data into your database.
Performance
Speed where it counts, from load times to slow queries.
Load and responsiveness
How quickly your key pages load and become usable. A slow first impression loses people before they ever sign up.
Database queries
Slow queries and the pattern where an app quietly hits the database far more than it needs to, a classic generated-code bottleneck.
Caching
Where expensive work and repeated requests could be cached, since the right caching cuts both your costs and your response times.
Asset sizes
How your images, scripts and bundles are served, since these are often far larger than they need to be.
Scaling
Whether it holds up as real users and data arrive.
Handling many users at once
Whether the app can run on more than one instance and handle simultaneous users without corrupting shared state.
Database capacity
Indexes, connection limits and room to grow, so the database doesn’t become the thing that falls over as usage climbs.
Long-running work
Slow jobs like emails, exports and AI calls, which belong in the background instead of blocking requests and timing out.
Third-party limits and cost
The rate limits and pricing of the services you depend on, especially cloud hosting and AI APIs, so a busy day doesn’t break the app or produce a shocking bill.
Deployment and operations
Shipping safely: deploys, rollbacks, monitoring and cost.
Repeatable deploys
How you release, and whether it’s reliable and repeatable, ideally with some automation, so shipping isn’t a nervous manual ritual each time.
Configuration and secrets
How configuration and secrets are handled across environments, rather than hard-coded or shared between your development and live setups.
Rolling back
Whether you can quickly undo a bad release. Being able to roll back turns an outage into a minor blip.
Monitoring and alerts
Whether you would hear about a problem through uptime checks and error alerts, rather than finding out from your users.
Cost control
The things that cause bill surprises, such as uncapped AI usage, oversized infrastructure and missing budget alerts.
Code quality and maintainability
Whether the codebase is safe to change and hand over.
Structure and readability
Whether the codebase is organised well enough for you or a future developer to change it safely. AI can produce a lot of code quickly, and it doesn’t always hang together.
Tests
Whether the important paths have any tests. Even a handful around the critical flows makes future changes far less risky.
Dependency hygiene
Unused, duplicated or abandoned dependencies that quietly add risk and weight to the project.
Documentation and handover
Whether there’s enough written down for someone new to run the project and understand how it fits together.
Accessibility and correctness
That it works for real people, across devices, browsers and inboxes.
Accessibility basics
The essentials, such as keyboard use, colour contrast, labels and screen-reader structure, so you’re not shutting people out or falling short of your obligations.
WCAG compliance
How your app measures against the Web Content Accessibility Guidelines, the standard many organisations are expected, and increasingly legally required, to meet.
Forms and validation
Whether the forms give clear feedback and handle mistakes sensibly, since that’s where most people get stuck.
Devices and browsers
How the app behaves across the browsers, screen sizes and devices your users actually have, from desktops to phones and tablets, not just the setup it happened to be built on.
Email rendering
The emails your app sends. HTML email is notoriously inconsistent, and a message that looks right in one client can fall apart in another, so the common clients are worth checking.
What you get
The 8-point Launch Plan
Every one of the 8 areas below, worked through by a senior engineer against your actual code and your running app. Each finding is ranked by how much it really matters, written in plain English, with the technical detail needed to act on it.
One plan that tells you exactly what stands between you and a confident launch, and the order to tackle it in. It’s yours to keep, whether I do the work next or you do.
Summary
22 findings
Let’s get your app launched
Start with an honest, prioritised picture of what sits between you and a confident launch, then let me help you put it right. Fixed price to start, no obligation.