How do you know a store needs a fix, not a rebuild?
Three situations where the decision to rebuild gets made without any data. Waiting costs you another skipped platform release, and a diagnosis is €860 net and 10 working days, a fraction of what a new build costs.
It's slow, but nobody knows why
One person blames the hosting, another the theme, a third the modules. Each answer comes with a different bill, so the gap between them is worth measuring before you pay for any of them.
Core changes nobody remembers
Fixes written straight into the platform's files instead of into overrides block every future update. You only see them once an update breaks something that had worked for years.
Modules with no owner
Dozens of modules, some disabled, some from contractors nobody can reach any more. Without a risk-rated list, every change to the store is a bet.
What is an online store technical audit?
A PrestaShop technical audit is a one-off diagnostic service: a review of the layer the buyer never sees, meaning the server, the platform core, modules, code and security. It ends with a list of fixes ordered by impact on sales, not by the order we happen to find them in. Implementing the fixes is a separate decision and a separate quote, and the report stays yours no matter who you give it to. The first question is where the biggest risk to sales sits, the second, only after that, is what can be sped up.
PHP version, limits, cache, database and server configuration. This is usually where the difference between a fast store and a slow one sits, even with the same code.
How current the core is, the architecture of overrides and hooks, modules and their effect on response time. This layer decides whether the store can even be updated.
Backups, access, known vulnerabilities and single points of failure. This part answers the question of what happens when something goes wrong.
Scope of a PrestaShop store audit: server, code and modules
- ✓ Server configuration, PHP version and limits
- ✓ How current the PrestaShop core and modules are
- ✓ Performance: TTFB, cache and Core Web Vitals
- ✓ Security: access, permissions, known vulnerabilities
- ✓ Core modifications, overrides and hooks
- ✓ Database architecture and multistore configuration
- ✓ A report with fixes ordered by priority
Four reasons clients put off an audit
An audit leaves nothing visible behind in the store. That's why it gets put off longer than almost anything else, usually until the first serious outage.
“The store works, so there's nothing to audit”
Working is too low a bar. An outdated core, modules with known vulnerabilities and changes written straight into the platform don't get in the way of sales until the day you need to upgrade the version or add an integration. At that point the bill covers everything that built up along the way.
“This will probably end in a quote to rebuild the store”
The audit ends with a list of priorities, not a build proposal. Sometimes the result is a server config change and disabling three modules, and that's exactly what we write in the report. You can stop there and implement the fixes with your own team.
“Our agency says everything's fine”
That's exactly why the audit is done by someone who doesn't maintain the store. We check core modifications, database architecture and server configuration, the places where the last few years of decisions show up. The report goes to you, not to your current agency.
“We don't have anyone to hand access to”
We need three things: panel access, server access and a list of integrations. If any of them can't be pulled together, that's the first finding of the audit, not a reason to postpone starting it.
How is a technical audit different from SEO, speed and care?
A technical audit checks the store's engine: server, core, modules, performance and security, and ends with a prioritised list of fixes. An SEO audit asks about catalogue visibility. Speed optimisation is carrying out one of those fixes, and post-launch care is monthly upkeep of the store, not its diagnosis.
The audit is a closed product: a fixed price, ten working days, and a report that stays yours even if you don't keep working with JustIdea afterwards. After the diagnosis you have three routes, and the audit doesn't decide any of them for you: your team implements the fixes, a single fix is picked up as a standalone service, or post-launch care takes over the whole thing.
This is the right service
- The store slows down or falls over during promotions and nobody knows why.
- You're taking over a store from another contractor and want to know what you're getting.
- You're planning a PrestaShop update and don't know what will break.
Start somewhere else
- The store works and the problem is Google rankings: that's a store SEO audit.
- You already know it's a speed issue: that's speed optimisation.
- You want someone watching it every month: that's post-launch care.
- The store runs on a different platform and you want to switch: that's migration to PrestaShop.
Ten working days, area by area, starting from access
The clock starts once we have something to work with, not once the contract is signed. This is the order of work and where we need your team.
- 1
Access and a list of integrations
2 working days
The store panel, the server, and a list of the systems the store exchanges data with. Pulling together and checking this access usually takes two days. If any of it can't be reconstructed, that's the audit's first finding, before the audit itself even starts.
- 2
Automated scan
2 working days
Core and module versions, known vulnerabilities, server configuration, database size and health, performance measured across three page types. Tools do this part, which is why it fits into two days.
- 3
Manual review
4 working days
Changes written straight into the core, theme modifications, integrations failing silently. No scanner finds this, and it's usually where the most expensive problem is hiding.
- 4
Report and call
2 working days
A list ordered by impact, split between what your team can close and what needs a developer. We finish with a call about priorities, so the document doesn't end up sitting in a folder.
Five findings that keep coming up in store audits
Core and modules several releases behind
The store works, so updating isn't a priority, and every skipped release raises the cost of the update that has to happen eventually anyway. On top of that come modules with publicly documented vulnerabilities: if the description is public, more than just the store owner knows about it.
Changes written straight into the platform's files
Someone once needed a single fix and took the shortest route. Changes like this leave no trace in version history, vanish on the next update, and are usually the reason behind the claim that a store 'can't' be upgraded. We list them by file name, so they can be moved somewhere they'll actually survive.
A database bloated with tables nobody reads
Connection logs, search statistics and template caches can take up many times more space than products and orders combined. The result is slower queries across the whole store and backups that take hours to restore instead of minutes.
Silent failures in integrations
The warehouse or accounting integration stops answering some requests, and nothing shows it, because nobody's watching the logs. The gap surfaces weeks later, during stocktaking or a complaint, and by then it's a commercial problem, not a technical one.
Emails that never reach customers
Order confirmations and cart reminders land in spam because the domain's authentication records aren't set up correctly. This finding has been costing sales for months, and it's fixed on the DNS side in under an hour.
When to run an online store audit: four moments
An audit ordered for no particular reason ends up as a report in a folder. These are situations where it has a concrete job to do.
Before switching agency or contractor
An independent description of the store's state, before anyone starts explaining why things are the way they are. The new team gets a starting point, and you get leverage in the conversation about scope and price. This is the most common reason the audit gets ordered with us.
Before a major build
A new integration or a basket rebuild on a store with core changes and modules from several years back costs more than the same work on a tidy store. An audit lets us quote it before the start, instead of discovering obstacles mid-project.
After a run of unexplained outages
The store goes down every few weeks, each ticket gets closed separately, and nobody sees the pattern. An audit looks at the whole picture at once: logs, load, integrations, the database. A recurring outage almost always has one cause, just rarely the one visible in the ticket.
Before deciding on migration
Before committing to a platform switch, it's worth knowing how much of today's problems come from the platform and how much from how it was implemented. Sometimes the cheaper route is tidying up what you already have, and then we recommend exactly that, even though migration would be the bigger job for us.
What else can we do for you?
A store is several layers at once: catalogue, technology, visibility and measurement. A PrestaShop technical audit touches one of them, and the others are covered by the neighbouring services.
Store SEO audit
An SEO audit and e-commerce catalogue analysis: categories, product pages, filters and the feed.
View ›Post-launch care
Technical care for a PrestaShop store as an hours package: updates, monitoring of integrations and performance, feature development and a contracted response time.
View ›Migration to PrestaShop
We move your store from Shoper, Shopify, Magento or a custom-built system.
View ›Who writes this audit, and how others rate them
The outcome of an audit is read by a developer, not a shopper, so trust in the contractor matters more here than usual. The three ratings were left by clients on public platforms, and Clutch confirms every review with a call to the client.
weighted average of 224 reviews across three platforms. Clients gave them, and each site links to the profile with the full text of every review.
Read the reviews ›
Responsiveness, an understanding of our needs and taking the initiative are what let us call our joint project a success.
They were always one step ahead of the competition, optimizing campaigns in real time.
Their responsiveness and strategic approach made them a reliable and results-driven partner.
A recommendation is only as good as our knowledge of the next release
The audit ends with a list of tasks ordered by priority, and that priority depends on what the maker changes in the next release. These are the statuses that knowledge comes from.
PrestaShop Expert ★★★
JustIdea is in PrestaShop's agency programme, which gives us the requirements of upcoming releases before publication and a route to report core bugs. That means the audit never recommends working around something the maker is about to fix in the next version.
Top E-commerce Developers Kraków 2026
A ranking of e-commerce developers. An audit is most often ordered by someone who isn't yet a client of ours, and Clutch verifies every review of that kind of engagement with a call to the author.
base. (BaseLinker)
A silent failure usually sits in the integrations, not the store itself: stock levels or order statuses drift apart. This integration partnership gives us documentation and support access on base.'s side when diagnosing that.
PrestaShop technical audit: questions before you decide
How much does a technical store audit cost?
€860 net, regardless of store size, and the WooCommerce variant costs the same. The timeline is 10 working days from when we get access. This is the price of a standalone service, not a deposit on implementation: you can hand the report to any contractor or to your own team.
What exactly does a PrestaShop technical audit cover?
Server configuration and PHP version, how current the core and modules are, performance measured by TTFB and Core Web Vitals, security, a review of core modifications and the database architecture. The result is a report with fixes ordered by priority, not a list of everything that could theoretically be improved.
Does the audit commit me to further work with you?
No. It's a standalone service for €860 net, the document is yours, and you can take it anywhere, including to your own team. We designed it that way on purpose: the decision to implement anything should rest on numbers, not on a promise.
How long does the audit take and what do you need to start?
Ten working days from when we get access. We need the admin panel, the server or hosting, and access to Search Console and Google Analytics if performance needs to be measured against your real traffic.
How is a technical audit different from an SEO audit?
One criterion: a technical audit answers whether the store works, an SEO audit whether it's visible. Here we look at versions, core changes, server response time and database health. When a store loses performance under load or stops responding at peak hours, this is where we start. When it runs stably and the problem is rankings and search traffic, the right choice is a store SEO audit.
Is the audit safe for a store that's currently live?
Yes. We work read-only: we read configuration, code and logs, we don't change settings or deploy fixes. We run vulnerability scans in a way that doesn't add load during sales hours. If anything did require touching the store, we'd ask first.
Does the audit include penetration testing?
No. We check for publicly known vulnerabilities in the core and modules, permission configuration and common places data leaks happen, but we don't run controlled attacks on the store. Full penetration testing is a separate service, on different terms and under a separate agreement.
Do you implement the fixes after the audit?
Implementing the fixes is a separate decision and a separate quote. We write the report so it can be handed to anyone: every task has a description, a reason and an effort estimate. If the list comes down to speed, the right service is speed optimisation. If there are many fixes and they'll keep coming back monthly, that's post-launch care. Some items your team will close on its own, and we say so directly on the list.
Which platforms do you audit besides PrestaShop?
WooCommerce stores, at the same €860 net price and the same 10-working-day timeline. The scope is equivalent, just the platform layer differs: instead of modules and core changes, we look at plugins, the child theme and conflicts between them.
Does the technical audit cover SEO and UX?
To the extent that they depend on technical factors. We check whether a search engine can properly crawl the store: URL structure, redirects, meta tags generated by the theme, speed and mobile page loading. These affect rankings and search visibility, but keyword and content strategy isn't in scope, that belongs to an SEO audit. It's the same with UX: we list technical faults that break the purchase path, such as navigation that doesn't work on mobile, while a full analysis of the path to conversion is a UX audit.
Do you check customer data protection?
From a technical angle, yes. We look for places personal data could leak: publicly accessible database backups, logs with customer addresses, and modules with outdated permissions. Customer privacy also depends on who has access to the panel, so we review accounts and roles. We don't issue a legal opinion on GDPR compliance, that's a job for a lawyer.
Book 30 minutes about your store
After the call you know whether your store needs an audit, a migration, or neither.
