10 Review & continuity
Technical audit & architecture consulting
A written review of a system you run or a decision ahead — architecture, data model, code, dependencies, security and operations — with findings in priority order.
Outcome: What to fix first, what can wait — and why.
A technical audit is a written review of software you already run, or of a technical decision ahead. It covers architecture, data model, code quality and tests, dependencies, security posture and how the system is deployed and operated — and ends with findings in priority order, each with its trade-offs.
It fits before building further on an existing system, when inheriting one from another developer or agency, or when choosing between a rewrite and gradual change. Making the changes is a separate step — for example software modernisation & maintenance.
Typical needs
- A major technical decision ahead, or doubts about an existing system
- Plans to build further on software no one has examined closely
- Technical risk that has to be explained to people who don’t read code
What you receive
- A written review with prioritised findings and their trade-offs
- A recommended order of work, including what to leave as it is
- A short summary for decision-makers, with the technical detail behind it
Approach
How the work runs.
- 01
Questions and scope
The review starts by agreeing which questions it has to answer — about a decision to make, a risk to size up or a system inherited from someone else — and which parts of the system it covers.
- 02
Reading the system
Code, data model and migrations, dependencies, access rules, secret handling and the deployment and CI setup are read directly, then checked against how the system is actually used and released.
- 03
Findings and trade-offs
Each observation is weighed against the agreed questions: what it puts at risk, how soon it matters and what fixing it would take. Sound parts are recorded too, so they are not changed without reason.
- 04
Sequence and walkthrough
Findings are ordered into a recommended sequence of work and walked through with you, in English or Serbian, so questions are answered before anything is changed.
Technologies
- TypeScript
- Next.js
- Node.js
- PostgreSQL
- Python
The engineer who does this work is the founder, Filip Volf — you work with him directly.
Questions
About this service.
What does the written review contain?
A short summary for decision-makers, then the findings: for each one, where it is in the system, why it matters, how urgent it is, the options with their effort and risk, and a recommendation. It closes with a recommended sequence of work and a note of what is sound and should be left alone.
How is a technical audit different from software modernisation & maintenance?
The audit ends with the written review: what to change, in what order and why. Software modernisation & maintenance is the change itself — upgrades and migrations in small, tested releases, then ongoing maintenance. One can follow the other, but the review stands on its own: you can act on it with your own developers or anyone else.
What access does the review need?
Read-only access to the repository, database schema and migrations, and deployment and CI configuration, plus a conversation with whoever runs the system. Secret values are not needed; production data only if a specific question depends on it. The review covers TypeScript, Node.js, PostgreSQL and Python systems, and it does not test or change a live system.
Related services
- 05
APIs, backend architecture & PostgreSQL
Outcome: Business rules enforced once, where the data lives.
- 09
Security-aware architecture
Outcome: Security decisions made deliberately — and written down.
- 11
Software modernisation & maintenance
Outcome: The software you already rely on, safe to change again.
Next step
Let’s talk about what you’re building.
Describe what you need built or fixed, how the work runs today and the constraints. You get clarifying questions or a first outline of the approach — by email, in English or Serbian.