Cursor code review, from prototype to a production-ready codebase
Cursor writes in hours what used to take days, but fast AI iteration does not mean production ready. I review the repo, architecture, security, CVEs and infrastructure of your Cursor-built app and keep the code under ongoing technical oversight afterwards, instead of stopping at a one-off check.
- Baseline from 790 €
- Fixed monthly plans
- Repo + CVE + infrastructure
- German point of contact
Direct point of contact
Timo Wevelsiep
Software engineer, cloud architect, founder & managing director
I review code, security and infrastructure and surface what is technically risky before launch, customer use or due diligence.
I have delivered production software, infrastructure and cloud systems for clients worldwide, including Europe, the UAE, Asia, Australia and the Americas: from automated multi-location platforms and cloud migrations to remote access systems for industrial plants.
For questions like:
- Is this release production-ready?
- Which CVEs are really critical?
- Are auth, data access and tenant isolation clean?
What Cursor does well, and where risks appear
Cursor is strong at quickly building features, boilerplate and refactors. That same speed creates gaps that only show up under load. These are the patterns I see most often in Cursor codebases:
- inconsistent error handling across different modules
- duplicated logic re-generated several times by prompt
- secrets and API keys in .env files or in the repository
- file upload without size, type and path checks
- missing integration tests despite many unit stubs
- architecture drift: a grown structure without clear boundaries
Why fast AI iteration needs regular review
With Cursor the codebase moves not per sprint, but per prompt. Every new feature adds new dependencies, every refactor can quietly break an assumption from the last iteration, and what was clean two days ago is already restructured today. A review from yesterday often describes a codebase that no longer exists in that form.
Cursor optimises for working code, not for long-lived architecture or security. The editor does not warn you when the same logic appears for the fourth time, when an upload endpoint stays unchecked, or when an outdated dependency brings a known CVE along. Those decisions are still made by humans, or by no one.
That is why fast AI iteration and regular review belong together. Not as a brake, but as a guardrail: spotting architecture drift early, closing security gaps before the next feature, and keeping the codebase production ready step by step instead of starting one big cleanup project at the end.
What I review
I look at the points that decide production readiness and rank every finding by severity. I review:
- Repo and architecture: structure, duplicated logic, dependencies, drift
- Security and access control: auth, roles, exposed secrets, upload paths
- CVEs and dependencies: known vulnerabilities in the packages you use
- Error handling and tests: consistency, integration tests, edge cases
- Infrastructure, deployment, backups and monitoring
- Production readiness: what is still missing before real users
One review is not enough: ongoing reviews
A one-off check describes the state on a single day. With Cursor code that state goes stale fast: every iteration adds new paths, new CVEs surface every week, and the architecture shifts with every larger prompt. An action plan that is four weeks old often no longer fits the code.
You get the app reviewed once (Baseline) and then keep it under ongoing technical oversight with Oversight, Guard or Launch. That turns the one-off photo into continuous oversight that keeps up with the pace of your iterations.
That keeps the risk dashboard current: new dependencies and CVEs are watched continuously, risky changes are flagged early, and before larger releases you get a human judgement instead of an automated score.
Baseline vs. ongoing plan
You start with a one-off review and then decide whether ongoing reviews make sense. Prices are fixed and transparent.
| Baseline 790 € | Plan from 990 €/mo | |
|---|---|---|
| Scope | Deep initial baseline: repo, architecture, dependencies, config | Recurring reviews based on the baseline |
| Result | Risk dashboard, CVE baseline, secrets check, architecture notes | Recurring reports with fix prioritisation |
| CVEs and dependencies | Full baseline as a reference point | Ongoing CVE and dependency monitoring |
| Support | One-off, with a recommendation for the right plan | Async sparring and a direct channel by plan |
| Best for | Clean starting point before any plan | Cursor projects that evolve fast |
How the Cursor code review works
- 01
01 Fit check
Free first contact: a short description of the Cursor project, the tools in use and the goal. I clarify whether a Baseline or an ongoing review fits the situation.
- 02
02 Scope and access
Defining which repositories and environments are reviewed. Read-only access is set up, and sensitive areas and open questions are flagged up front.
- 03
03 Technical analysis
Repo and architecture are checked for architecture drift, unclear module boundaries, duplicated logic and missing tests, complemented by security, exposed secrets, CVEs in dependencies and infrastructure.
- 04
04 Report and recommendations
Findings sorted by severity, with a risk dashboard, prioritised findings and concrete next steps: fix now, fix before launch or plan for later.
- 05
05 Next step
From the Baseline a recommendation follows on whether and with which plan (Oversight, Guard or Launch) the fast-growing Cursor code should be supported on an ongoing basis.
Many projects start with a Baseline review. If the product keeps being built with AI afterwards, I can support it on an ongoing basis.
What I need for the review
- read-only access to the repository
- a short description of stack, tool and goal
- details on hosting and deployment
- database and auth context
- notes on sensitive data or user roles
- open questions or concrete concerns
What the review delivers
- an understandable risk dashboard
- top risks at a glance
- prioritised findings
- concrete recommendations
- guidance: fix now, fix before launch, plan for later
- an optional recommendation for Oversight, Guard or Launch
What a finding looks like
Upload endpoint accepts arbitrary file types and paths without validation, possible path traversal and storage abuse. Recommendation: enforce a type allow-list, a size limit and a server-side target path.
One-off check or ongoing reviews?
| One-off check | Veriploy ongoing | |
|---|---|---|
| Timing | Point-in-time snapshot on a fixed date | Continuous, with every new iteration |
| CVEs and dependencies | State on the review day | Ongoing monitoring with alerts |
| Architecture drift | Not covered | Drift and duplicates are flagged early |
| Before a release | Another check needed | Human judgement included in the plan |
| Assessment | Action plan at the end | Human prioritisation, not just a score |
Frequently asked questions
Do you only review Cursor code?
No. I review the repository, not the tool. Code from Cursor can be reviewed just like code from Claude Code, Lovable, Bolt or hand-written code. Cursor is in focus here only because fast AI iteration produces architecture drift and duplicated logic especially quickly.
Is this a penetration test?
No. Veriploy is an ongoing technical review of repo, architecture, security, CVEs and infrastructure, not a classic pentest. A pentest can complement it well when you want to simulate targeted attacks. I continuously check whether your Cursor code is production ready.
Do you also do the fixes?
Not within the plan. I review, prioritise and explain what needs to be done, such as merging duplicated logic or securing an upload endpoint. Implementation runs separately through Wevelsiep Advisory or WZ-IT, or your own team. That keeps the review independent from the implementation.
Do you need repo access?
Yes, read-only by default. Read access to the repository is enough for the review. I do not need write access, because I do not commit the fixes myself.
What does it cost?
The entry point is fixed: Baseline 790 € as a one-off review. Ongoing reviews start at 990 € per month (Oversight), then Guard at 1.950 € and Launch at 3.900 € per month. All prices net plus VAT. Ongoing packages start with a 3-month minimum term, then cancelable monthly, unless agreed otherwise.
How fast do I get results?
I deliver the Baseline within a few business days. On an ongoing plan you get regular reports and a prompt heads-up on critical CVEs.
- Get your Claude Code project reviewed, architecture, security and infrastructure in view
- CodeRabbit alternative? When a tool is enough and when a human should look at the repo, CVEs and infrastructure
- AI code review tool or human technical oversight?
- Get your AI app reviewed, with ongoing technical oversight instead of a one-off gut check
Do you recognize these risks in your own app?
The AI-app risk self-check assesses product status, stack, auth, data access, infrastructure, CVEs and your technical knowledge, and shows whether a review makes sense.
Get your Cursor code reviewed and keep it monitored afterwards.
Start with the Baseline, then ongoing reviews in the plan that fits.
Check repo fit
Briefly describe the project.
Direct contact with me, no anonymous ticket system. I get back to you with a first assessment and the right entry point.
Timo Wevelsiep
Software engineer, cloud architect, founder & managing director