Technical Audit

Free consultation Projects

An answer to the question that is blocking your roadmap - grow what exists, replace a part of it, or move the product onto a different foundation. A verdict, a debt register priced in days of team time and three two-year scenarios, in 15 working days.

We have worked with leading companies and startups

Challenges

Three situations in which an audit gets ahead of an expensive decision

Not sure whether an audit is the right step right now? Book a consultation - we will say plainly whether a dependency review is enough or the case calls for a full assessment.

  • „You are taking over code from a previous vendor”

    A maintenance contract or a product handover is signed against a state nobody on your side has yet seen from the inside. The audit gives you that picture before the signature - what you are inheriting, what cannot be maintained without its author, and which obligations belong in the contract instead of being discovered in month three.

  • „Every release takes longer than the one before”

    The team has not changed, individual tasks have not grown, yet the path from idea to production stretches quarter after quarter. We settle whether the brake is the architecture, the missing tests or the release process itself - because each of those causes has a different price.

  • „A proposal to rewrite the product is on the table”

    The engineering team wants to start from scratch, the board asks whether that is really necessary, and both sides argue with things that cannot be weighed. A verdict grounded in your repository and your measurements turns that dispute into a decision with numbers, one you can defend in front of an investment committee.

Who it is for

Who commissions a technical audit from us

  • Teams taking a product over from an external vendor

    The code arrives together with the maintenance contract, while the knowledge about it stays with the side that wrote it. We start from what can be maintained without its author - where the code is the only documentation, which integrations have a single owner, and what has to be transferred in the first weeks, before contact with the previous team goes quiet.

  • Companies ahead of an investment or an acquisition

    The deck shows the product from the market side, while the investor's question is what it costs to maintain what sits underneath. We provide the technical picture in a format that goes into the transaction file - with a register of obligations and a two-year range for the cost of maintenance.

  • Product teams with a slowing roadmap

    Quarterly plans close less and less completely, even though neither the team nor the size of the tasks has changed. We separate causes that look identical from the outside - architecture that forces changes in several places at once, missing tests that drain the team's nerve, and a release process that eats days on its own.

  • Companies with a system written in-house by one person

    The system runs the company's daily work, has done for years, and has exactly one person who knows how to start it. The audit describes that state without judging its author - what is documented, what has to be reconstructed, and in what order to hand areas over so that this person's departure does not stop operations.

Four printed interface layouts on a desk: a dashboard, a phone screen, a form and a table, with one block circled in marker

Our difference

How our approach differs

  • An audit for a product decision, not a penetration test

    We are a UX agency with a development arm and we examine one thing - whether this code can be built on and what that will cost in team time. Penetration testing, compliance against security standards and reviewing infrastructure for attack surface are a different specialism; we flag the obvious neglect, and where the need is real we point you to a team that does this for a living.

  • Debt priced in working days, not in labels

    A "high priority" rating tells the board nothing it did not already know. Every register entry gets an estimate of how many team days it consumes per year and what exactly it blocks in the plans, so the conversation about the order of fixes runs in the same currency as the conversation about the roadmap.

  • We read the code where the repository shows traffic

    Reviewing randomly chosen files says about as much about a product as opening a book at a random page. The change history points to the areas most of the team's work passes through, and those get the bulk of our attention - because that is where every future change will cost the most.

  • The verdict is written before any talk of implementation

    The recommendation does not depend on whether we later get the rebuild work. If the assessment shows the stack is healthy and the problem sits in the process or in headcount, that is exactly what we write - including the scenario in which you do nothing further with us beyond this audit.

Process

15 working days from access to verdict

  1. Day 1–2

    Scope and access

    We agree what enters the assessment - which repositories, environments and integrations. We take read access, whatever documentation exists, and a list of the people who own each area.

  2. Day 2–5

    Architecture and dependencies

    We map the split into modules and services, the boundaries of responsibility, how data is stored and where the product touches external systems. Separately we review the libraries - versions, update cadence, end-of-support dates and known vulnerabilities.

  3. Day 4–8

    Code where it changes most often

    The repository history points to the files with the heaviest traffic - that is where we read the code most carefully, because every future change will pass through exactly there. We check test coverage, duplication and the places where one fix forces five more.

  4. Day 7–11

    Performance and the path to production

    We measure how the product behaves for real users and under laboratory conditions, how it holds up under heavier load, and how long a change takes from approval to production - plus what happens when it has to be rolled back.

  5. Day 9–12

    Conversations with the team

    An hour with each person who maintains the product day to day. We ask where the work jams, what everyone avoids and what they think will break at ten times the traffic. Those answers usually aim better than any automated tool.

  6. Day 12–15

    Verdict and decision session

    We assemble the report, the debt register and the three scenarios, then run a two-hour session with the engineering team and whoever owns the budget. You leave with a chosen path, not with material to think over.

Deliverables

Three documents, the first of which opens with the verdict

  • A report with an unambiguous recommendation

    The first sentence of the report says outright what to do next - keep building on this stack, replace the module we name, or move the product onto a different foundation. The rest is the reasoning: an architecture map, dependencies with their end-of-support dates, the areas with the heaviest traffic in the repository and the performance measurements.

  • A debt register priced in team days

    Every entry is described by what it actually blocks - how many working days it consumes over a year, which roadmap item it holds back and what happens if it sits untouched for another year. The sheet sorts by cost, not by a "critical" label, so it goes straight into quarterly planning.

  • Three paths with the consequences worked out

    Growing the current code, replacing selected modules and moving the product onto a new foundation - each path with its horizon, its risk and a list of the things you will not do while taking it. We work them out over two years, because in a shorter window patching always looks cheaper than it is.

Toolkit

What we apply

Public metrics and standards instead of a scoring scale of our own - the point is that you can repeat our measurement without us and compare the result six months later.

A workbench from above: two printed interface layouts, a magnifier enlarging one block, a steel ruler and a greyscale step wedge running from white to black, with one line underlined in orange marker
  • Core Web Vitals - LCP, INP, CLS
  • Lighthouse and WebPageTest
  • The four DORA metrics
  • ISO/IEC 25010 - quality characteristics
  • Repository history analysis
  • Dependency and known-vulnerability review

Next step

Let us talk about your project

Tell us what you have to do. We will come back with scope and a quote.

Free consultation Projects

Selected work

Projects from the products we audit

A cross-section of web apps, admin panels and company websites - the products where we most often assess the stack before a build decision. The reports themselves describe client code, so we show them only during a consultation.

Projects

Outcomes

What the audit leaves behind, and when

  • 15–20 days

    Working days from handing over access to the verdict and the decision session - several repositories or a native app alongside the web move the deadline towards twenty

  • 3

    Technical scenarios on the output, each with its horizon, its risk and a list of the things you will not do while taking it

  • 2 years

    The horizon we cost each scenario over, because in a shorter window patching always looks cheaper than replacement

  • Core Web Vitals

    The public set of Google metrics we use to describe performance for real users, not just in a single Lighthouse run

The deadlines, the number of scenarios and the costing horizon come from the scope and schedule described above on this page; Core Web Vitals is a public Google standard. We do not publish results from specific audits - the report and its debt register are the client's document and describe the client's code, so we show excerpts by name during a consultation.

Client voices

What our clients say

  • „Working with the Wzór team was a genuinely great experience! They always answered our questions quickly and were flexible about our comments. They have no shortage of creative ideas and are at the same time thoroughly reliable and on time. The end result fully met our expectations; we recommend them to anyone looking for professionals who care.”
    Maja Wieloch-Silecka Operations Director, Bosfor Group
  • „Our clients expect us to act fast and effectively across a very wide scope - from building a brand, through a website with a store, to running an effective sales campaign. Not an easy task, but doable when you have a tight-knit team and partners who take on challenges on the fly. For us, quality, accountability and commitment are key, and working with UX Agency Wzór gives us that 100%.”
    Piotr Alberski Chief Operating Officer, Agencja XO Media
  • „Our cooperation with UX Agency Wzór started with our own website. We really liked the way they work, so we decided to subcontract projects for our clients to them on a White Label basis. We loved their workflow, the way they hand projects over to our team, their documentation and their work on the design system. Now we can take on bigger risks.”
    Mateusz Swół Chief Operating Officer, Sellace

Time and scope

How long the audit takes and what the quote depends on

15–20 working days

Fifteen days is enough for one product in one repository, with access to a test environment and performance data. A split across several services, a native app alongside the web, or the absence of any documentation move the deadline towards twenty days - the first week then goes on reconstructing the picture we normally receive at the start.

  • The number of repositories, services and integrations in scope

  • The size of the codebase and the product's age counted in years of change

  • The extent of access - repository read rights, test environments, performance data

  • The platforms in scope - web, native app, data layer

  • The number of conversations with the team maintaining the product

  • Whether the scenarios are to cover data migration

FAQ

Questions that come up most often

How much does a technical audit cost?

The quote depends on a few things - the number of repositories and services in scope, the product's age counted in years of change, whether we get access to a test environment and performance data, the number of platforms (web alone, or web together with a native app), and whether the scenarios are to cover data migration. We set the scope in a thirty-minute call and send the quote with a schedule within two working days. Book a call - we will also tell you if a narrower review is enough in your case.

Is this a security audit?

No. We are a UX agency with a development arm, and we assess whether a product is fit to be built on, not how it holds up under attack. We do check what cannot be missed while reading code - libraries with known vulnerabilities, secrets kept in the repository, missing access control in the obvious places - but commission penetration testing and compliance against security standards from a team that does only that. We are happy to point you to one during a consultation.

Do we have to give you access to the code?

For a full verdict, yes - read access to the repository and a test environment is enough. Without the code we can still assess the outer layer, meaning performance for users, the behaviour of the programming interfaces, observability and the release path, but then we speak about architecture and debt from circumstantial evidence rather than from measurement. We say so plainly at the start, so nobody expects a stronger recommendation than the material allows.

Will you tell us to rewrite everything?

That verdict comes out rarely. Most often the problem turns out to concentrate in one or two areas that most changes pass through, while the rest of the code will comfortably last for years. If, however, the measurements show the foundation will not carry your plans, we will write that without softening it - together with the price of such a decision and what you lose while the move is under way.

How does this differ from a UX audit?

Different question, different material. A UX audit assesses whether the user reaches their goal, and looks at the product from the screen side. A technical audit assesses whether you can keep building on it, and looks from the side of the repository, the architecture and the performance measurements. Sometimes one problem shows up in both - a slow product list is at once an abandoned path and a query against an unindexed table.

Who runs the audit on your side?

A senior developer reads the code, measures performance and talks to your team, while the person responsible for the product translates those findings into consequences for the roadmap and the budget. That way the report is not a list of technical remarks but material you can take to the board. You know the line-up before we start, by name.

We only have a proposal from a software house - can the stack be assessed from documentation?

The proposal can be assessed, but that is a different exercise from auditing an existing product. In that case we check whether the proposed technologies fit the scale and the rate of change you are assuming, where the offer stays silent about maintenance costs, and which questions to put to the vendor before signing. The output is shorter and comes faster, because there is nothing to measure - only something to compare against the plan.

Do you then implement the recommendations?

We can, but that is a separate contract and a separate decision. The verdict is written before any conversation about implementation, so the scenario in which your own team does the work is treated in the report on equal terms with the others. Some clients take the debt register to their team and come back six months later for a repeat measurement of the same metrics - that is a good way to use this document too.

Related services

Related services

Book a free consultation with an expert to discuss your project and get answers to your questions.

- Patryk Korycki, CEO

Schedule a meeting
Book a free consultation