— 01
Want to understand the real state of the project before investing more
Technical
Audit
of the Project.
I'll review the architecture, code, security, and performance. You get a clear problem description with priorities and concrete recommendations — not a list of complaints, but an action plan.
Independent assessment
Code
Architecture
Security
Infrastructure
Timeline
3–7
Result
Report + plan
01 — Who it's for
Who needs a technical project audit?
— 02
Planning to hire a developer and want to know what they'll be working with
— 03
Project is slow or crashing — unclear exactly where and why
— 04
Changed contractors and want an independent assessment of what was done
— 05
Preparing for load growth and want to verify the system can handle it
— 06
An investor or partner requests a technical assessment before a deal
02 — What I review
Six areas of the technical audit
code · architecture · security · infra
I look not just at the code, but at how the project lives in production
Good code in poor infrastructure is just as dangerous as bad code in good infrastructure. The audit covers the entire stack: from architectural decisions and code quality to server configuration, backups, and monitoring.
PHP / Laravel
JavaScript / TypeScript
React / Next.js
PostgreSQL / MySQL
Docker / Linux
OWASP Top 10
01
Architecture and project structure
Architecture that's invisible from the outside
The project may look fine externally, but inside — business logic in controllers, God Objects of 2000 lines, circular dependencies between modules, and complete absence of separation of concerns. This isn't an aesthetic problem: it's the reason every new task takes three times as long as it should.
What I check
Layer separation: controllers, services, repositories, models. Module size and cohesion — any God Objects or Spaghetti Code. Dependencies between components: is there circularity, is the single responsibility principle honored. Whether the chosen architecture matches the project's actual requirements.
How I document the result
I describe architectural antipatterns with concrete examples from the code — not 'poor structure', but 'OrderController.php has 800 lines of business logic that should be in services'. For each problem — a recommendation and an effort estimate for resolution.
02
Code quality and technical debt
Debt that doesn't appear in the backlog
Technical debt rarely makes it into the backlog — it lives in the code and accumulates invisibly. Logic duplicated in ten places, magic numbers without explanation, methods with six parameters, unpredictable side effects — each of these elements slows development and increases regression probability.
What I check
Code duplication and DRY violations. Function and method complexity — cyclomatic complexity, length, parameter count. Test coverage of critical business logic. Use of outdated patterns or libraries. Readability and documentation of non-trivial parts.
How I document the result
I categorize findings by criticality: blockers (blocking development now), important (accumulating debt), recommendations (good to fix when opportunity arises). Each category with examples from the code and a concrete fix approach.
03
Security
Vulnerabilities that don't surface in development
SQL injections via unparameterized queries, XSS via unescaped output, CSRF without tokens, insecure password storage, APIs without authentication, secrets in git repositories — this is the OWASP Top 10, still found in real projects today. The problem isn't ignorance — it's the pressure of deadlines: 'we'll add security later'.
What I check
OWASP Top 10: injections, XSS, CSRF, insecure deserialization, open redirects. Credential storage: secrets in code, git history, or config files. Session and authentication management. Authorization: ability to access other users' data or actions. Dependencies with known vulnerabilities.
How I document the result
For each vulnerability — risk level (critical, high, medium, low), plain-language description of the attack vector, and a concrete remediation approach. Critical vulnerabilities are highlighted separately — they should be fixed before anything else.
04
Performance and database
'It's slow' is not a diagnosis
'The page takes 8 seconds to load' is a symptom. The cause might be N+1 database queries, missing indexes, synchronous operations in the request, heavy computations without caching, or slow frontend rendering. Without measurement, it's guesswork, and 'optimization' often improves the wrong thing.
What I check
N+1 queries and suboptimal ORM usage. Indexes: which exist, which are missing, which are excessive. Slow queries via EXPLAIN ANALYZE. Cache usage: what's cached, what should be, any invalidation issues. Core Web Vitals and frontend performance.
How I document the result
Specific queries with their actual execution time and plan. List of missing indexes with estimated gain. Caching recommendations specifying exactly where and for how long. Estimated performance improvement after fixes.
05
Infrastructure and DevOps
A server nobody has properly configured
The project works, but: deployment is done manually via FTP or SSH commands, backups haven't been tested since setup, there's no monitoring and outages are reported by users, secrets are stored in .env directly on the server without rotation. This is the standard picture for projects where DevOps was 'done by the developer on the side'.
What I check
Deployment process: reproducibility, rollback on error, downtime. Backups: frequency, storage, restore testing. Monitoring: uptime, errors, slow queries, disk space. Secret management: where stored, who has access, is there rotation. Software versions: PHP, Node.js, dependencies — current? Any known vulnerabilities?
How I document the result
An infrastructure risk checklist with priorities. I separately highlight what could lead to data loss or extended downtime — these are first-priority fixes regardless of the rest of the audit.
06
Dependencies and technology stack
An outdated stack is a growing risk
PHP 7.4, Laravel 8, Node.js 14, jQuery 1.x — all out of active support. Critical vulnerabilities in these versions won't be patched. Meanwhile, migrating through several major versions is a non-trivial task that gets harder with every month of delay.
What I check
Core dependency and framework versions — currency and support status. npm/composer audit: dependencies with known CVEs. Abandoned packages: libraries without updates for more than two years. node_modules size and frontend bundle size. Duplicate dependencies solving the same problem in different ways.
How I document the result
A list of dependencies with vulnerabilities, prioritized by risk level. For outdated frameworks — an update effort estimate and recommendation: update now, plan it, or replace with an alternative.
03 — How we work
Four stages — from access to a finished report
Get access
Repository, read-only server access, link to a working environment. I sign an NDA if needed. No changes to code or configuration — read-only.
Conduct the audit
I review the code, architecture, configuration, and infrastructure using a structured checklist. I document findings with concrete examples, not abstract statements.
Prepare the report
A structured document: findings by category, criticality level for each, concrete code examples, and remediation recommendations. A summary with the top-5 priorities.
Review together
A call to go through the report: I answer questions, explain priorities, and help form an action plan. You leave with a clear understanding of what to do next.
04 — Result
What you get after a technical audit
Not a list of complaints, but a
concrete action plan
A structured report describing each problem, its consequences, and how to fix it. Priorities are clear — you know what to do immediately, what to schedule, and what's already good. A review call is included.
Report with concrete examples
Every issue — with a file, function, and explanation of why it matters.
Priorities by risk level
Critical, important, recommended — clear distinctions without vague language.
Review call and action plan
We go through the report together and form the order of fixes based on your resources.
When to start
The best time for an audit is before a problem, not after
An audit costs less than one serious incident: a data breach, extended downtime, or an architecture rewrite under load. Even if everything 'works fine' — an independent assessment shows how sustainable that actually is. Audit cost is fixed before we start. No changes to the code.
I usually respond within an hour
first call is free
working together
online
<1 day
response time
1:1
direct, no middlemen
0 ₽
for the first call
Quick replies
within the day
Single developer
full context, always
05 — FAQ
Common questions about technical audits
What do I need to provide for the audit?
Access to the repository and, if possible, read-only access to the server or staging environment. If you have architecture documentation or known issues — share those too, it helps focus on what matters. I sign an NDA if needed.
Will you make changes to the code?
How long does the audit take?
Can I order an audit of just one area?
06 — Other services
Related engagement formats
from the services catalog
see all →
see all →