Complete your AI-built application

Build on what you already have

A prototype helps demonstrate your idea and expected behaviour. Questions may remain about where data is stored, who can access it and how to release changes safely.

I start with the available source code, build process and dependent services. For a project on a closed platform, I first check export options and development constraints. I then recommend what to keep and what to change.

What I check before launch

• Core flow: can users complete registration, an order or another essential task?
• Data and access: are changes saved correctly and can users access only their own records?
• Integrations: does a message or payment reach the next system, and what happens during an outage?
• Configuration: how are credentials managed and test and production environments separated?
• Operations: can you release a version, record errors and restore necessary data?

We define the review scope around the application features, data and connected services.

Security review of your AI-built application

Alongside visible features, I review data protection and how the application handles unauthorized requests. The checks focus on the authentication, backend and services your prototype uses.

• Authentication and permissions: user verification and server-side access checks, including separation of data between users or organizations.
• Databases and files: rules for reading and modifying records, access to stored documents and file uploads.
• API keys and passwords: whether credentials are exposed in browser code, the repository or logs, and how they are managed.
• Inputs and public interfaces: data validation, invalid request handling and measures to limit abuse of forms and APIs.
• Dependencies and configuration: known vulnerabilities in libraries and settings for test and production environments.

I prioritize findings by severity, recommend fixes and recheck affected areas after implementation. We define the scope upfront; if the project needs specialized penetration testing, I recommend arranging it separately.

GDPR, cookies and related legal requirements

I review technical privacy settings and whether user-facing information matches how the application actually works. We tailor the scope to the data processed, target users and external tools involved.

• Personal data and GDPR: I map collected data, purposes, storage locations, recipients and configured retention periods. I check the technical ability to locate, export, correct or delete records under agreed rules.
• Cookies and tracking: I inspect cookies, analytics, advertising pixels and embedded services actually loaded. For technologies requiring consent, I check blocking before consent, refusal and later withdrawal.
• Forms and consent: I review access to privacy information, separation of optional consent and records of consent and withdrawal. The legal basis is assessed for each purpose; consent is not an automatic requirement for every form.
• External services and AI: I prepare an overview of providers and shared data to support review of processing agreements and any transfers outside the EU/EEA.
• Legal information and orders: I compare operator details, privacy and cookie notices, and applicable terms with application features. For paid services, I check pricing, subscription information and cancellation, complaint or withdrawal flows against a legally approved brief.
• Licences and content: I map the provenance and available licences of libraries, images, fonts and other materials, flagging missing records or terms that need review.

You receive technical findings, recommended changes and questions for legal counsel. A lawyer handles legal interpretation and approval of legal documents; I help implement their requirements and verify application behaviour.

What you receive after the assessment

You receive a summary, security findings, privacy configuration issues and material for legal review, together with recommended fixes and a prioritized plan. I separate issues to resolve before launch from later improvements and document the review scope and anything that remains unverified.

The output includes a proposed next phase and a scope estimate with assumptions. You can then decide whether to proceed with completion.

Completion costs depend on the current state

The number of finished screens does not reveal the remaining work. A functioning backend, data quality, testability and external dependencies matter.

I compare repairs and partial replacement in terms of effort, risk and maintenance. Read more in the guide to vibe coding and working with a developer.

What to prepare for the first conversation

Send a demo link, the platform used and a description of the main task. Explain what works, where you got stuck and whether you have the source code.

Anonymized examples are enough to start. Repository and test environment access can be agreed once the assessment scope is clear.