We review the code, the architecture, the integrations, the environments and the dependencies of your platform. The report shows which problems need a response, which can be planned for later, and what you need to know before taking a store over, rebuilding it or growing it further.
The service is for companies that already run an e‑commerce store but are not certain that its current technical state lets them make the next set of changes safely. The scope is matched to the technology, the level of customisation and the decision the audit is meant to support.
Technical debt rarely shows up as a single, easily named bug. More often it shows in rising estimates, recurring regressions, integrations watched by hand and the reluctance to run a larger update.
One signal on its own says little about the platform as a whole. Problems that repeat, with no clear explanation of their cause, are what justifies a wider analysis.
| Signal | Possible cause | Consequence |
|---|---|---|
| A small change carries a large estimate | Tight coupling between modules, duplicated logic or missing documentation | The backlog moves more slowly and the cost of a change is harder to predict |
| A fix in one place breaks something in another | No regression tests, or dependencies the team cannot see | Releases call for caution and longer manual verification |
| Orders or stock levels have to be checked by hand | The integration handles neither errors, nor retries, nor alerts | The operations team takes on work the system should be doing |
| Updates keep being postponed | Module conflicts, outdated dependencies or no repeatable release process | Maintenance costs and security risk both grow |
| Only one person understands a given area | The knowledge was never written into the code, the tests or the documentation | One specialist leaving can stall part of the platform |
| Every agency judges the store differently | There is no shared documentation, no criteria and no supporting material | Decisions rest on opinions rather than on findings anyone can check |
A small change carries a large estimate
Possible cause
Tight coupling between modules, duplicated logic or missing documentation
Consequence
The backlog moves more slowly and the cost of a change is harder to predict
A fix in one place breaks something in another
Possible cause
No regression tests, or dependencies the team cannot see
Consequence
Releases call for caution and longer manual verification
Orders or stock levels have to be checked by hand
Possible cause
The integration handles neither errors, nor retries, nor alerts
Consequence
The operations team takes on work the system should be doing
Updates keep being postponed
Possible cause
Module conflicts, outdated dependencies or no repeatable release process
Consequence
Maintenance costs and security risk both grow
Only one person understands a given area
Possible cause
The knowledge was never written into the code, the tests or the documentation
Consequence
One specialist leaving can stall part of the platform
Every agency judges the store differently
Possible cause
There is no shared documentation, no criteria and no supporting material
Consequence
Decisions rest on opinions rather than on findings anyone can check
Finding faults is not the goal in itself. Before we start we settle which decision is to be made once the analysis is in, and which areas can bear on it.
A technical audit is worth considering in the following situations:
You need to establish the state of the code, the extent of the customisation, how the integrations behave, which environments exist and what the documentation is missing. Without that, a new team can take on responsibility for problems whose scale nobody measured.
A new market, a B2B model, an extensive integration or a rebuild of the buying process can touch many parts of the system. The audit shows which parts of the current architecture need putting in order first.
Estimates get higher while the features themselves do not look more complicated. The cause can be accumulating technical debt, the absence of automated tests, or areas of the platform bound too tightly together.
Recurring regressions can mean that the team is removing symptoms without reaching the cause, or that it lacks the tools to verify a change safely.
The audit shows what can still be grown, what needs rebuilding and where the cost of keeping the current solution may stop being justified. The scope of a migration itself is settled later, in a separate analysis.
Some dependencies exist only in the memory of current or former developers. There is no documentation, no description of the integrations, no history of the decisions and no repeatable way of releasing a change.
If the store has not launched yet and the project has stalled short of going live, the starting point is usually finishing a Magento 2 store, which begins with a review of what has already been built.
The list below is the basis for setting the scope. Before the audit starts we establish the technologies, the environments available, the integrations that matter most and the decision the report is meant to support.
We look at how responsibility is divided between modules, how tightly they are coupled, how much logic is duplicated, and which places are hardest to build on.
Among other things we check
Kind of evidenceCode extracts, a map of dependencies between modules and a list of overrides against the platform standard.
We check where third-party components come from, how current they are and what they do. We assess conflicts, overrides, duplicated functionality and any reliance on solutions that are no longer maintained.
The report separates what is needed, what is redundant and what calls for a decision of its own.
Among other things we check
Kind of evidenceA dependency list with versions, the change history in the repository and the package manager configuration.
The analysis covers how data moves between the store and ERP, PIM, WMS, CRM, payment providers, carriers and other services.
Among other things we check
Kind of evidenceConnection configuration, data exchange logs and the procedure followed after a failed synchronisation.
We verify the settings that bear on the security of the platform, the roles and permissions, how secrets are stored, how current the components are and how far the environments are exposed.
We do not present a technical audit as a penetration test unless that scope has been agreed separately.
Among other things we check
Kind of evidencePlatform settings, the list of accounts and roles, and the server configuration as far as it is made available.
We check how the environments are split, how a release is prepared, how configuration changes are handled, whether a release can be rolled back and how a change is verified before it goes live.
The point is to establish whether the team can release repeatably and respond when a new version causes a problem.
Among other things we check
Kind of evidenceThe release pipeline configuration, the deployment history and a description of the steps still done by hand.
We look at which events are recorded, who receives alerts and whether the team has the data it needs to reconstruct what happened during a failure.
Missing diagnostic data usually stretches out a fix, because the problem has to be reproduced first instead of going straight to its source.
Among other things we check
Kind of evidenceLog samples, the monitoring configuration and the history of recent incidents.
We check whether the most important processes are covered by tests, whether the documentation matches the current state of the system, and how much knowledge sits with single individuals.
The assessment also covers whether another team could take the code over.
Among other things we check
Kind of evidenceTest coverage in the repository, the project documentation and the instructions for setting up the environment.
We look at how responsibility is divided between modules, how tightly they are coupled, how much logic is duplicated, and which places are hardest to build on.
Among other things we check
Kind of evidenceCode extracts, a map of dependencies between modules and a list of overrides against the platform standard.
We check where third-party components come from, how current they are and what they do. We assess conflicts, overrides, duplicated functionality and any reliance on solutions that are no longer maintained.
The report separates what is needed, what is redundant and what calls for a decision of its own.
Among other things we check
Kind of evidenceA dependency list with versions, the change history in the repository and the package manager configuration.
The analysis covers how data moves between the store and ERP, PIM, WMS, CRM, payment providers, carriers and other services.
Among other things we check
Kind of evidenceConnection configuration, data exchange logs and the procedure followed after a failed synchronisation.
We verify the settings that bear on the security of the platform, the roles and permissions, how secrets are stored, how current the components are and how far the environments are exposed.
We do not present a technical audit as a penetration test unless that scope has been agreed separately.
Among other things we check
Kind of evidencePlatform settings, the list of accounts and roles, and the server configuration as far as it is made available.
We check how the environments are split, how a release is prepared, how configuration changes are handled, whether a release can be rolled back and how a change is verified before it goes live.
The point is to establish whether the team can release repeatably and respond when a new version causes a problem.
Among other things we check
Kind of evidenceThe release pipeline configuration, the deployment history and a description of the steps still done by hand.
We look at which events are recorded, who receives alerts and whether the team has the data it needs to reconstruct what happened during a failure.
Missing diagnostic data usually stretches out a fix, because the problem has to be reproduced first instead of going straight to its source.
Among other things we check
Kind of evidenceLog samples, the monitoring configuration and the history of recent incidents.
We check whether the most important processes are covered by tests, whether the documentation matches the current state of the system, and how much knowledge sits with single individuals.
The assessment also covers whether another team could take the code over.
Among other things we check
Kind of evidenceTest coverage in the repository, the project documentation and the instructions for setting up the environment.
What the audit covers
What a technical audit does not replace
A technical audit can establish that a problem needs measuring further, but it does not replace:
Both look at the same platform, but they answer different questions. The technical audit judges the quality of the solution and the risks of developing it further. The performance audit measures how fast the store is for a user.
The quality of the solution and the technology risks
Judges the code, the architecture, the modules, the dependencies, the integrations, the security and the technical debt. It answers whether the platform can be safely developed, taken over or maintained — and at what cost.
Speed and the user experience of it
Focuses on speed, Core Web Vitals and the user experience tied to performance. It measures response times, behaviour under load and the bottlenecks on specific views.
A technical audit can point out that an area needs measuring — it then says what to measure, not what the number is. If the problem is primarily how fast the store is, the performance audit is the right first step.
Technical debt rarely comes from one bad decision. It is usually the sum of changes made under deadline pressure without tidying up what was left behind. An audit names those places and shows what they cost on every change that follows.
What technical debt is made of
Not all debt has to be repaid. The report separates the areas that block further growth from the ones you can knowingly live with — along with what that decision costs.
Taking a project over without checking its state moves obligations nobody has counted onto the new supplier. An audit run before development starts turns them into a list of known risks.
What we check before a takeover
An audit does not end in a verdict of “good” or “bad”. For each area it names one of three roads, along with its cost and its consequence.
The area meets the standard, or its gaps do not block further growth. Work carries on with what is there, and the smaller fixes go into the plan.
The solution works, but maintaining it costs more than rebuilding it. The report sets out the scope and the order, so the change does not stop sales.
A module, an integration or a mechanism whose maintenance cost is not covered by its value to the business. Retirement or replacement rather than repair.
If the decision is less about the state of the current platform and more about what should be built, the right starting point is a pre-implementation analysis. For a project another supplier started and never finished, store completion is a scope of its own.
Taking a platform over calls for one scope, an assessment before a large integration for another, and a decision about keeping the current architecture for a third.
The stages run in order, and each has a stated input and result. That makes it clear what we need from the client's team, and when.
We gather information about the platform, the team, the current problems and the changes planned. We establish who will use the report and which decisions should follow from it.
NeededTechnology, integrations, planned changes, current supplier, history of the main problems
ResultA written statement of the decision the audit is to support
We prepare the list of repositories, environments, logs, documentation and people with knowledge of the system that we need. Any limits on access are recorded, and the report draws no categorical conclusions about an area it could not examine.
NeededApprovals, accounts and named contacts on the client's side
ResultAn agreed scope, together with the areas left out of the analysis
Specialists work through the agreed areas, record the evidence and assess how the problems depend on one another. Findings are grouped by their effect on the platform and on the decisions planned.
NeededAccess to the code, the configuration, the logs and the documentation
ResultA set of findings, each with its supporting material
The most important observations are checked against the documentation and against what the client's team knows. That separates deliberate architectural decisions from leftovers of earlier changes.
NeededA conversation with the people who know the history of the project
ResultFindings confirmed or withdrawn, with the reasoning stated
We hand over a report with the findings, the evidence, the consequences, the priorities and the recommended options. We go through the conclusions with the people responsible for technology and for e‑commerce.
NeededA date for the meeting and the list of people receiving the report
ResultA prioritised report and a discussion of the directions open to you
Naming a problem does not yet say what the company should do about it. Every problem is written in the same chain, through to an estimate of the work — so the report can be read straight through, by area or by priority.
The report states the weight of the problem, the recommendation, the effort and the estimate for fixing it, so a backlog can be built from it and a budget discussed without repeating the analysis.
| Field | Content |
|---|---|
| Problem | The ERP synchronisation has no visible retry process after a failure. |
| Area | Integrations and the flow of data. |
| Risk level | High — a failure ends in divergent data rather than in an error message. |
| Impact | Some orders may need checking by hand once a synchronisation is interrupted. |
| Recommended fix | A queue with retries, event identifiers, and an alert for the team once a failure threshold is passed. |
| Priority | After the findings that block sales, before tidying up the structure of the code. |
| Estimated effort | A range of hours for the recommended fix, noting what has to be settled before it can be quoted. |
The format of a single problem
The ERP synchronisation has no visible retry process after a failure.
Integrations and the flow of data.
High — a failure ends in divergent data rather than in an error message.
Some orders may need checking by hand once a synchronisation is interrupted.
A queue with retries, event identifiers, and an alert for the team once a failure threshold is passed.
After the findings that block sales, before tidying up the structure of the code.
A range of hours for the recommended fix, noting what has to be settled before it can be quoted.
An example of the format. It is not the result of any client's audit.
The report holds
If the findings show that a problem needs measuring under real traffic, the next step is an e‑commerce performance audit. The technical report says what to measure, not what the figure is.
The report is handed over in a form an internal team, the current supplier or another company can use. The document is meant to be useful even when Aurora Creation does not carry out the work that follows.
The questions that come up most often about price, access, scope, security and using the report.
The first conversation is a qualifying one: we check whether a technical audit is the right step, and what has to be ready before it starts.
Let's discuss the scope and the access neededBack to Audit and analysisA basic audit starts at 3600 zł net. A wider scope is priced on the project: the number of integrations, the level of customisation, the number of environments, how much documentation exists, and whether the evaluation is to cover the database, the infrastructure and the release process. We confirm the figure and the dates before the work starts.
It depends on the size of the platform, the number of integrations, the extent of the customisation, how much documentation exists and the purpose of the analysis. The scope, the schedule and the way it is billed are confirmed before the work starts. A basic audit is markedly shorter than one covering the database, the infrastructure and the full release process.
The list depends on the scope agreed. It can cover the code repository, a test environment, the admin panel, logs, integration configuration, documentation and the tools used to release changes. Access to production should not be required where the data we need can be obtained safely from elsewhere.
Yes. Judging code quality, conformance to the platform standard, the extent of the overrides and the state of the custom work is the basis of a technical audit — without access to the repository some findings would stay guesswork. Where access to the code is not possible, we say plainly which conclusions cannot then be drawn.
It covers how current the components and software versions are, the configuration, accounts, roles, permissions and visible technical risks. It should not be treated as a penetration test — that scope is agreed separately where the situation calls for it.
Yes. For every integration we check the configuration of the connection, the direction and scope of the data exchanged, the error handling, the retries, the event identification, and what happens after a failed synchronisation. That covers CRM, payments, carriers and marketplaces in scope too.
A technical audit judges the quality of the solution: the code, the architecture, the integrations, the security and the technology risks. An e‑commerce performance audit focuses on speed, Core Web Vitals and the user experience tied to performance. The technical audit covers signals that can bear on performance, but detailed front-end, server and load measurements belong to the performance audit.
Yes, and it is one of the most common uses of this service. Before further development starts we check the repository, the documentation, the environments, the integrations, the security, the backlog, the code quality and the dependencies. The result shows which areas can be carried on with, which are worth rebuilding, and which cannot justify being kept.
Yes, as a separate scope agreed once the priorities are approved. It is not a condition, though: the report is handed over in a form an internal team, the current supplier or another company can use. For a project another supplier started and never finished, store completion is a scope of its own.
The technologies we implement and maintain ourselves: Magento 2, including front ends built on Hyvä and Luma, Shopify and Pimcore. The scope is matched to the technology of the store, but the structure of the evaluation stays the same. If a platform falls outside that range, we say so before preparing an offer.
No. The audit can be run as an independent analysis. The report can then be used by the current supplier, by an internal team or by another company.
The analysis does not include production changes unless they are agreed separately. Where we find an urgent risk, we report it first, together with a proposed way of handling it.
It can establish the limits of the current architecture and the risks of building on it. If migration turns out to be a justified option, its scope and technology should be settled in a pre-implementation analysis.
The report gives an estimate of the work for every problem, along with its priority and the dependencies between fixes. It is not a contractual quote for the whole of it, though: on some findings we note what has to be settled first, because some work cannot be estimated reliably from an observation of the problem alone.
The report can be used to put a backlog in order, to talk to the current supplier, to prepare a handover, to plan a refactor or to start a pre-implementation analysis.
In the first conversation we go through the current platform, the problems, the decisions ahead and the material available. If a different kind of analysis fits the situation better, we will say so before preparing a scope.
You do not need a technical write-up ready. What you currently have doubts about, and the decision the company is planning, is enough.
Worth having to hand
