A written picture of the store you have, and the first five things to do about it.
A read-only technical audit of a Magento Open Source, Adobe Commerce or Mage-OS store: release, PHP, extensions, performance, exposure and integrations, written up with a prioritised plan you own. For merchants who have inherited a store or want a second opinion before spending. The price is agreed in writing before we start.
Three situations we hear about every month.
We took over the store from another agency and nobody can tell us what is in it.
Nobody has read it end to end. Until someone does, every estimate is a guess and every change a risk.
We have one quote for an upgrade and one for a rebuild, and they are miles apart.
Neither has been checked against the store. An audit tells you which job the store actually needs.
The store is slow and we do not know whether it is the hosting, the theme or the extensions.
It is usually a mix, and measuring is cheaper than guessing. The audit names the slow parts and their causes.
Six areas, each read from the store itself, each written up in plain words with a severity and a recommendation.
Where the store sits in Adobe's calendar, PHP end of life, and the database, search, cache and queue.
Every module with its vendor, version, maintenance state and whether it is actually used.
Server response, field and lab data, cache hit rates, indexers, cron, and the queries behind the slow pages.
Reachable admin and API paths, two-factor, the edge in front of the store and any sign of past compromise.
Payment, shipping, ERP, marketing, search and feeds: how each connects and which are erroring today.
Everything ordered by risk and cost, the first five things to do, and an honest view on upgrade, Hyvä or migration.
Hyvä build for dormeo.co.uk and dormeo.ie, with a continuing programme of consent, tracking and security work.
Core Web Vitals, real-user data (Chrome UX Report), mobile, 28 days to 31st October 2026. Marks show Google's thresholds.
Rowan and his team have been excellent at website development. He is extremely responsive and goes above and beyond to achieve the desired goal. …
Read-only throughout. Nothing on the live store changes while we look.
Send us the store address. A senior engineer reads its release, support status, PHP, headers, hosting and any sign of a hijack.
Within two working daysWe list the read access we need, confirm what the audit covers and agree the price before we start.
Day oneCode, configuration, extensions, database, server, logs and scheduled tasks, read by a senior engineer, with findings recorded against each area.
Most of the auditPerformance measured on the pages that earn money. Headers, reachable paths and the edge checked from outside, read-only, with your knowledge.
Alongside the readingFindings by area with severities and recommendations, and the prioritised plan at the front.
On deliveryBoth are written by a person. One reads the store from the pavement; the other goes inside with your keys.
We price the work, not the clock.
An audit is priced as a whole. We tell you the price in writing before we begin, based on the size and shape of your store, and it stays the same unless you ask for the scope to change. No figure appears here because a single-store catalogue and a multi-store estate with an ERP behind it are not the same job.
Decades of collective experience across Magento 1, Magento 2, Adobe Commerce, Hyvä and Shopify. Very little about your store will be new to us.
You deal directly with the founder. No juniors learning on your store and no account managers between you and the people doing the work.
Small stores and large ones, described in their owners' words. The reviews are quoted on this site word for word.
Read access, and nothing that changes the store: the code repository or a copy of the codebase, a read-only admin account, and read access to the server or hosting panel so we can see PHP, the database, logs and scheduled tasks. Where a staging copy exists we use that for anything that has to be executed. Nothing changes on live during an audit.
No. The free health check reads only what your store already shows the world, on one page, with no access. The audit goes inside: code, configuration, extensions, database, server and integrations, and ends with a prioritised plan. The health check tells you whether to worry; the audit tells you what to do.
The plan is written so that anyone competent can act on it, including your in-house team or another agency, and you own the document. We are happy to estimate the work it describes, and we would rather you chose us because the audit was good than because it was vague.
Yes, and that is the most common reason we are asked. An audit is the right first step when you have inherited a store, are unhappy with the current arrangement, or want a second opinion before a large spend. We report what we find without editorialising about who built it.
A scanner tests a store from outside and produces a list. An audit reads it from inside, puts each finding in the context of your release, extensions and hosting, and says which five things matter first. Security is one of six areas, not the whole.
You get the written report and a call to walk through it. From there you can act on the plan yourselves, ask us to estimate any part of it, or put the store on a support retainer and work through it month by month. Nothing in the audit commits you to anything further.
It depends on the size and shape of the store: a single-store catalogue and a multi-store estate with an ERP behind it are different jobs. We tell you the price in writing before we begin, and it does not change afterwards unless you ask for the scope to change.
Yes. For a Magento 1 store the audit also lists every extension and customisation with its Magento 2 equivalent, which is the groundwork for a Magento 1 to Magento 2 migration.
Before an audit, see what the store tells the world: release, support status, PHP, headers, hosting and any sign of a hijack, on one page, by email, within two working days. Nothing is accessed or tested, and no obligation follows.
What we would do first. Apply the outstanding security fixes, then plan the upgrade to a supported release.