Technical audit

A technical audit of what already runs: code, architecture, infrastructure, security and interfaces. The deliverable is a report with priorities: what to fix now, what can wait, and what will have to be rebuilt.

An audit is commissioned when something is going wrong and the cause is unclear. The product is slow, every release breaks one thing or another, the developer says everything has to be rewritten, and nobody on the business side can judge what that costs or whether it is necessary at all. Another common reason: you are about to buy a business or take a project on and want to know what is inside before you sign.

One thing deserves saying plainly. An audit is not our way of selling development. The report often contains the conclusion that something works fine and should be left alone, and for us that conclusion is as much a result as a list of problems. After that you are free to do anything: fix it with your own team, hand it to another contractor or postpone it. There is no obligation to order work from us.

We look deep rather than across the surface. Code and architecture, infrastructure and the release procedure, security and the handling of data, performance under load, interfaces and the paths people take. We separately flag anything that rests on a single person: those places are more dangerous than any technical mistake.

And about the format of the result. The report is not a list of remarks for the sake of a list. Every finding comes with its consequences, a priority and a rough cost of fixing it, so that the decision is made on money and risk rather than on intuition. Afterwards we walk through it with your team and answer questions.

If after the audit you need to decide how to build further, that is IT consulting, and if the question is what to automate and whether it will pay off, business consulting. The fixes can be handed over in full under outsourcing or your team can be reinforced through outstaffing. An example of a project where the cost of a mistake was high is Ubix.Exchange.

01

What the service covers

Any combination of the items below can be taken on its own.

Code and architecture

How the project is built, where the bottlenecks are, what is duplicated, where the decisions were unfortunate and what that will cost as it grows.

Infrastructure and releases

How the product is deployed and updated, what happens on failure, whether backups exist and whether they actually restore.

Security and data

Access and permissions, secret storage, handling of personal data, common vulnerabilities, dependencies with known problems.

Performance and load

Page and response times, behaviour under load, database queries, caching.

Interfaces and scenarios

Where people stop, which steps are superfluous, what breaks on a phone, on long data and on errors.

Report with priorities

Findings, consequences, priority and an estimate of the cost of fixing. Plus a separate list of what should be left alone.

02

How we work

01
Access and introduction

We get read access to the code and the infrastructure, talk to your team and find out what hurts.

2-3 days
02
Review

We read the code, look at the configuration, walk the scenarios and run the project ourselves where that is possible.

1-2 weeks
03
Checks and measurements

Speed measurements, verification of backups, checks for common vulnerabilities and dependencies.

in parallel
04
Report and walkthrough

We write up the findings, set the priorities, cost them and go through the report with your team.

3-5 days
03

Cases for this service

04

Frequently asked questions

Read access to the repository and the infrastructure, and a few hours of your developer time for questions. Without that an audit turns into guessing from the outside.

No. The report is yours, do with it what you like. We are equally comfortable with you making the fixes yourselves.

One to three weeks depending on the volume of code and the number of systems. We name the price after a short introduction to the project.

No, that is the usual situation. We work it out from the code and from conversations with the team. The absence of documentation will itself appear in the report as a risk.

No. We look at the code, the configuration, the access and common vulnerabilities. Full penetration testing is separate work, and if it is needed we will say so.

Yes. People often ask us to look only at the infrastructure or only at security. The scope is agreed in advance.

We sign an NDA before receiving any access. The report goes to you only.

05

Related services

Shall we discuss your task?

Tell us what needs to be done and we will come back with an estimate, the team composition and a plan for the first two weeks.

2026 FAMOUS.TEAM digital interactive agency