Software gebouwd met AI? Wij zorgen dat ze overeind blijft wanneer kopers en stakeholders kritische vragen stellen.

Een eerste doorlichting van je project

Open je project in de AI-tool waarmee je het gebouwd hebt (Claude Code, Cursor, Copilot, Lovable, Bolt…) en plak deze prompt erin. Je AI zoekt alles zelf uit in de code, verandert niets en laat wachtwoorden en persoonsgegevens uit het rapport. Mail ons het rapport en we zeggen je eerlijk wat ervoor nodig is.

De prompt is bewust in het Engels. Zo krijgen we elk rapport in dezelfde vorm, en je AI-tool begrijpt hem perfect. Je hoeft niets te vertalen: plak hem zoals hij is. Het rapport is dan ook in het Engels; vraag je AI gerust om het daarna voor jou in het Nederlands samen te vatten.

You are a senior software architect. This project was built by its owner, who is not a professional developer, with the help of AI tools. The owner wants to prepare it for production and for sale, with a focus on security and GDPR (EU standards). Your analysis will be sent to an independent software engineer, who will use it to estimate the size and complexity of the work and decide whether to take on the project.

Rules:
- Do NOT modify, move or delete any existing file. Analyze only.
- Work out everything yourself from the code and configuration in this project. Do not ask me questions.
- If something cannot be determined from the code, say so explicitly. Do not guess.
- The report will be shared outside this project. NEVER include passwords, API keys, tokens, connection strings, customer data or other personal data. If you find any, give only the file and line where they are, never the value.
- Write so that a non-developer can follow: explain technical terms briefly the first time you use them.

Write one report covering:

1. Summary: what the application does and for whom, as far as the code shows, and its main features.
2. Project size: languages used, approximate number of files and lines of code per language, number of database tables or collections, number of screens/pages and API endpoints. Rough numbers are fine; say how you counted.
3. Architecture: main components (core logic / engine, UI, backend, database), how they interact, tech stack, frameworks and key libraries.
4. Repository structure: key folders and files with a one-line description each.
5. Data flow: trace how data moves through the system step by step, from the moment it enters (user input, API, file upload) through processing, storage, and any output (UI, reports, emails, external services). For each step, name the files/modules involved.
6. External integrations: APIs, third-party services, AI models, and what data is sent to each.
7. Authentication & authorization: how it works, roles, session handling.
8. Security posture: secrets in code or config files, encryption at rest and in transit, input validation, logging, outdated or vulnerable dependencies (run the read-only audit tool for this stack if available, e.g. npm audit, pip-audit, dotnet list package --vulnerable).
9. Hosting & deployment: where and how the application is (or appears meant to be) hosted, configuration and environment handling, and anything that blocks a production deployment.
10. Quality & maintainability: automated tests and rough coverage, version control, CI/CD, documentation, code duplication, overall code consistency.
11. Technical debt: shortcuts taken for the demo that are critical before production.

Include Mermaid diagrams:
- A component/architecture diagram.
- A data flow diagram showing every step from entry to output.
- A sequence diagram for the most important user flow you identify.

Then give a prioritized list of the top 5–10 risks (security, GDPR, production readiness), each with severity (High / Medium / Low) and a one-line suggested fix.

End with a complexity assessment: overall size (Small / Medium / Large), code quality (Good / Fair / Poor) and production readiness (Ready / Needs work / Major work), each with a one-line reason, plus the 3 areas that will need the most work.

Save the complete report as one Markdown file named project-analysis.md in the root of the project. This is the only file you may create. Then tell me the report is ready.

In vijf stappen naar zekerheid

Van werkend prototype naar bewezen product

Een eerlijke verklaring waar kopers op kunnen vertrouwen

De validatieverklaring vermeldt de exacte productversie, de datum van de review en wat er gecontroleerd werd. Ze beweert niet meer dan wat nagekeken is, en net daarom nemen kopers ze ernstig.

Nieuwe grote versie? Een korte hercontrole houdt de verklaring actueel.