A technical audit is worth paying for only if it answers the question you actually have: fix this platform, or replace it, and in what order. This checklist is for technical leads, founders who code and developers who have inherited a system. Use it to scope an audit, to judge one you have received, or to run a first pass yourself.

Architecture and data

  • Is there a clear separation between presentation, business rules and data access, or is logic scattered across templates, plugins and handlers?
  • Does the data model match the business? Look for overloaded tables, stringly typed fields and relationships held together in application code.
  • How do integrations work: documented APIs with retries and idempotency, or fragile scripts and webhooks with no error handling?
  • Where does state live, and can the application scale horizontally without sticky sessions or local disk?

Dependencies and code health

  • Framework and runtime versions: how far behind supported releases, and how hard is the upgrade path?
  • Third-party packages and plugins: how many, how maintained, and how many known vulnerabilities?
  • Dead code, duplicated logic and copy-pasted AI output that nobody fully understands.
  • Type safety, linting and a consistent structure a new developer could follow.

Security

  • Authentication and session handling, including password reset and account recovery flows.
  • Authorization checked on the server for every request, not only hidden in the interface.
  • Secrets kept out of the repository and the client bundle, and rotated when people leave.
  • Input validation and output encoding against the OWASP Top 10, especially injection and access control.
  • Personal and payment data: what is stored, where, who can read it, and whether it needs to be kept at all.

Performance

  • Field data first: Core Web Vitals from real users where available, then lab tests repeated several times.
  • Break slow LCP into its parts: server response time, resource load delay, load duration and render delay.
  • Server response: hosting path, cold starts, caching, and how many sequential network calls a request makes.
  • Database: slow queries, missing indexes and N+1 query patterns under realistic data volumes.
  • Front end: render-blocking CSS, JavaScript shipped to the client, font loading and image sizing.

Delivery and reliability

  • Automated tests on the paths that make money: sign-up, checkout, quoting, ordering.
  • A CI pipeline that runs checks on every change and deploys the same way every time.
  • Rollback: how quickly a bad release can be undone.
  • Backups that have actually been restored in a test, not just scheduled.
  • Monitoring and alerting for errors, uptime and slow requests, with someone who receives the alerts.
  • Infrastructure defined in code or documented well enough to rebuild, and running costs that match the load.

What the report should give you

  • Findings ranked by business impact, not by how interesting they were to find.
  • Evidence for each finding: file references, measurements and steps to reproduce.
  • A sequenced roadmap: fix now, fix soon, fine as is, with rough effort for each.
  • A clear fix-or-rebuild recommendation and the reasoning behind it.
  • Enough detail that any competent developer can act on it, whoever does the work.