Skip to content
N1
Audit · problem map · stabilization

Legacy audit: find the cause, not treat the symptom

When the project already works but breaks, there is no documentation, and rewriting everything from scratch is risky — I first find the cause, then propose a safe plan.

When you need it

The developer left, the code stayed
No documentation
No logs
Processes break
Scary to touch production
You need the cause, not a "symptom fix"

What's included

Project structure overview Search for critical risks Logging check Integrations check Duplicate and data-error check Problem map Fix plan Timeline and budget estimate

How I work

  1. 1Minimal access
  2. 2Analysis of code and processes
  3. 3Recording risks and entry points
  4. 4Problem map and priorities
  5. 5Plan of safe fixes

How I assess project risk

Low risk
  • There are logs
  • There is a test environment
  • Entry points are clear
  • There is code access
Medium risk
  • No documentation
  • Few logs
  • Some processes on old cron/agents
  • There are manual workarounds
High risk
  • Production without backups
  • No logs
  • Hidden business logic
  • Code changed by many people
  • Unclear which data is critical

What the client gets

  • A clear problem map
  • Priorities and a plan
  • Timeline estimate
  • Recommendations on logs and architecture
  • Understanding of what can be left as is

Risks and limits

  • I do not touch production blindly
  • I make a backup when there is a risk of data loss
  • A full architecture rework — as a separate estimate

Approximate work formats

Express audit
1–2 days
Deep audit
3–7 days
Fix support
hourly / package

If the project is old, without logs or documentation, with unknown integrations or production risks — an audit comes first. Otherwise any exact estimate is just guessing.

What I will need to work

  • Minimal access to the system: Bitrix24 / repository / staging
  • Access to logs if the task is about errors
  • Description of the business scenario and expected result
  • For integrations: API docs, test keys, payload examples

How I handle access

  • I do not ask for excessive rights
  • Tokens and keys are never sent to public chats
  • For production changes — a separate user and a backup when there is risk
  • After completion access can be revoked

Related cases

FAQ

Can it be reworked without a full rewrite?

Yes, if the architecture allows. I first record risks and entry points.

What is needed for the audit?

Access to the code/test environment, a problem description and logs if available.

Will you name the fix price right away?

After the audit: without understanding the project's state an exact price is impossible.

Not sure where to start?

Just describe the problem. I will study the current solution, assess the risks and propose implementation options.