Implementation & Hardening – from prototype to a system

In the I step of the ANVIL system, your validated prototype becomes the MVP – the first market-ready version of a product. This is the moment where speed meets rigor. A working demo proves the idea holds; it does not prove the code withstands an attack, an audit, or real load. That is exactly the gap the I step closes: AI-accelerated development, hardening of every feature against the OWASP Top 10, every line in senior review. The prototype is no throwaway artifact; it's the most precise spec there is – it shows in black and white what the product needs to do, and it saves weeks of requirements workshops.

45%

of AI-generated code contains security vulnerabilities (Veracode 2025)

2.74x

more security issues in AI code than in human code (CodeRabbit)

+34%

exploitation of vulnerabilities as initial attack vector (Verizon DBIR 2025)

€3.87M

average cost of a data breach in Germany (IBM 2025)

Your validated prototype becomes an MVP

The I step builds directly on your groundwork. What you made with Cursor, Claude, Lovable, or a freelancer isn't scrapped – it's the foundation, because it already pins down what the product must do. Three terms, three levels of maturity, cleanly separated:

Stage	What it is	Where in the ANVIL system
Prototype	Your work – the working demonstration of your idea	Entry into the system
MVP	The first market-ready, hardened version with real users	Outcome of the I step
Platform	The scaled version, running in production	Outcome of step L

After the Analysis (Step A) that all four entry paths share, two paths land directly on this step: if you bring a prototype (the most common case), you enter here at I; if you want an existing, insecure, or fragile platform brought up to standard, you start at I or L. In either case, Step A has already produced a prioritized roadmap, and the way forward is clear. Our guide: From Prototype to Production lays out the path from prototype through MVP to platform in detail.

Hardening against the OWASP Top 10:2025

AI compresses build time from months to weeks – and reproduces the same flaws at the same speed. According to CodeRabbit's analysis of 470 pull requests, security issues appear up to 2.74x more often in AI code than in code written by humans alone; Veracode found that 45% of AI-generated code contains vulnerabilities. CodeRabbit: State of AI vs. Human Code Generation Report Veracode: GenAI Code Security Report 2025 That attackers target exactly this is borne out by the Verizon DBIR 2025: the exploitation of vulnerabilities as an initial attack vector rose 34% year over year. Verizon: Data Breach Investigations Report 2025

That's why the MVP is tested systematically against the ten most common risks in the OWASP Top 10:2025, and every finding is fixed: OWASP Top 10 (2025)

Broken Access Control – missing authorization checks, IDOR vulnerabilities
Security Misconfiguration – default credentials, verbose error messages, open debug endpoints
Software Supply Chain Failures – compromised dependencies, missing SBOMs, insecure CI/CD
Injection – SQL, NoSQL, and command injection
Cryptographic Failures – unencrypted transmission, weak algorithms
Authentication Failures – weak policies, missing MFA; we deploy Keycloak as a self-hosted identity provider with passwordless auth and magic links
Logging & Monitoring Failures – we implement structured logging with OpenTelemetry for complete traceability

The recurring patterns in AI-generated applications are the most expensive ones: hardcoded API keys, missing input validation, exposed admin routes, personal data in log files, and missing rate limits. A single figure shows how large the attack surface is: in 2025 alone, more than 28.6 million new secrets were exposed in public GitHub repositories. GitGuardian: State of Secrets Sprawl 2026 For a deeper look at the recurring patterns, see our article Vibe Coding Done Right; systematically hardening these weaknesses is a core part of Step I.

Every line in senior review: AI for speed, expertise for rigor

The principle is enforced through a fixed gate: AI tools like Claude Code generate the code, but no commit reaches production without a senior review and a green quality gate. Every line carries a named sign-off in the end – only then does it count as done. GitHub: Quantifying Copilot's Impact on Productivity (2022)

Automated test suite: Unit, integration, and E2E tests cover every feature. Every fix is anchored with a test so that vulnerabilities don't come back.
CI/CD with quality gates: Linting, security scanning, and a GitOps-based deployment pipeline. No commit reaches production without review.
Senior review of every line: No black box. Architecture decisions are documented and justified, and the code stays comprehensible for you and for any team that comes after.

The difference isn't academic. Snyk and Trivy run continuous vulnerability scanning – important because, according to Snyk and the Linux Foundation, 40% of all open-source vulnerabilities live in transitive dependencies that were never installed directly. Snyk & Linux Foundation: State of Open Source Security 2022

Hardened infrastructure, GDPR and NIS2 from day one

Hardening doesn't stop at the application boundary. The infrastructure defined in step N is secured on the principle of least privilege:

Network & WAF – least-privilege firewall rules, segmentation, web application firewall
TLS configuration – TLS 1.3, HSTS, Certificate Transparency
Container security – minimal base images, no root processes, image scanning, hardened K3s configuration
Secrets management – no credentials in code or environment variables, Vault integration

Compliance here isn't a bolt-on; it's part of the hardening: encryption at rest and in transit, access logs, deletion concepts, and a documented record of processing activities. The security-relevant NIS2 core measures under Article 21 are implemented in technical terms – relevant because, since December 2025, NIS2 requires documented cybersecurity measures from roughly 29,500 German companies. BSI: NIS2 Implementation in Germany For details, see our NIS2 Security Checklist, the page NIS2 for Web Platforms, and the GDPR Vendor Audit. The economic leverage is substantial: according to IBM, companies that use security extensively reduce their average breach costs by $1.9M and shorten the breach lifecycle by 80 days. IBM: Cost of a Data Breach Report 2025

How does the I step work?

Kriterium	Phase	Timeline
1. MVP build from the validated prototype	Core functionality, data model, API, and authentication on the target architecture from step N	Week 1–6
2. Hardening & OWASP Top 10	Remediation, rate limiting, input validation, secure headers, secrets management	Week 4–8
3. Tests & senior review	Automated test suite, CI/CD quality gates, review of every line	ongoing
4. Verification	Independent penetration test, regression tests, GDPR review	Week 8–10
5. Handover to L	Documented audit trail, security report, transition to Launch & Operations	Week 10

At the end of the I step there's a verifiable result, not a document: a running, hardened MVP with Git repository handover and documentation, a configured CI/CD pipeline with automated tests, a security report with the results of the penetration test, and architecture documentation for further development. From here it's just one step to Launch & Operations (L).

Why this discipline pays off over the lifetime of the system

The strict order – build first, then harden, no code in production without review – costs time in the moment and saves it over the lifetime of the system. Unhardened code doesn't disappear on its own; it becomes a liability. McKinsey puts technical debt at 20–40% of a company's entire technology estate, and Martin Fowler describes how it becomes the bottleneck of scaling companies. McKinsey: Tech debt – Reclaiming tech equity Martin Fowler: Bottleneck #01 – Tech Debt Every weakness closed during hardening is one that doesn't have to be fixed later under load, in an audit, or after an incident – when it's vastly more expensive.

Compared with continuing to run a vibe-coded project, the difference shows up precisely here: not in the demo, which runs in both cases, but in what comes after. The I step is the cheapest place to build in this discipline – every gap closed later costs many times more.

Do you have a validated prototype or a platform that needs to become production-ready? Send us a short description of your project. In an intro call, we'll discuss the concrete path to a hardened MVP.

Frequently asked questions

What is the I step – Implementation and Hardening?

The I step is the fourth stage of the ANVIL system. Your validated prototype becomes the MVP – the first market-ready version. Development continues AI-accelerated, hardened against the OWASP Top 10, every feature covered by automated tests, every line of code in senior review. The result is a system that holds up to a security audit and to real customers.

I have an AI-built prototype – do I start here?

Yes. The prototype path is the most common entry point and begins – after the Analysis (Step A) – directly in the I step. The prototype is no throwaway artifact; it's the foundation of the MVP: it shows exactly what the product must do, and that's exactly what we build on.

How is AI-generated code secured?

Through the duality of speed and rigor. AI tools accelerate development, but every line passes through a senior review and automated tests. Testing runs systematically against the OWASP Top 10:2025, every vulnerability found is fixed, and the fix is locked in with a test. The pace of AI stays; the vulnerabilities don't.

What's the difference between a prototype, an MVP, and a platform?

A prototype is your work – the working demonstration of your idea and the entry into the ANVIL system. The MVP is the outcome of this I step: the first market-ready, hardened version with real users, tests, and compliance foundations. The platform is the scaled version running in production – the outcome of the Launch step (L).

Is the MVP GDPR- and NIS2-compliant from the start?

Yes. Encryption, access control, audit logging, and a documented record of processing activities are part of the hardening. The security-relevant NIS2 core measures under Article 21 are implemented in technical terms, and hosting is EU-sovereign, without CLOUD Act exposure. What you get is an audit trail, not a mere statement of intent.

How long does the I step take?

Typically ten to twenty working days, depending on the scope of the validated prototype and the target architecture. MVP build and hardening run in overlap, senior review and automated tests run throughout. The Analysis (Step A) sets the exact scope before the build begins.