What really makes a B2B store complicated

Selling to businesses can look like an ordinary retail store with prices shown after login. It can also involve a customer with many branches, different buyer roles, limits, manager approval and negotiating part of the order. Both models are called B2B, but they require a different scope of implementation.

Before comparing platforms, describe the rules with examples. What does a customer’s employee see, and what does their manager see? Does the discount depend on the product, quantity, contract or account balance? What happens when a credit limit is exceeded? Can a salesperson change the offer, and does the customer have to approve it again? These answers define the structure of the system.

Also take into account the work after purchase. Partial availability, delivery from several warehouses, splitting an order and correcting an address all affect fulfilment. A choice based only on how the catalogue looks misses the place where the team may be doing the most manual work.

Where PrestaShop may be enough

PrestaShop offers specific prices, which can be tied to, among other things, a customer, a group and a product quantity. The vendor describes their configuration in the specific prices guide. So the need for an individual price is not yet in itself an argument for building a more complex solution.

If the company has a repeatable purchase process, clearly defined price groups and an ERP integration, check this option first. You need a trial on real rules: a customer with a contract price, a quantity threshold, a promotion and a change in the number of items. See whether the result also matches after the order is passed to the sales system.

Additional features may require modules. For each, check the vendor, updates, compatibility with the version you use and how it works with other add-ons. Several extensions don’t have to be a problem. The difficulty arises when several independent elements try to decide on the same price or order status at the same time.

Don’t set the threshold at, say, a hundred or five hundred business customers. A larger number of companies using one simple rule can be easier to handle than a small group with different purchasing processes. What matters is the number of rules and records, how often they change and the response time under a given load.

When it’s worth looking at Sylius

Sylius is developed as an e-commerce framework based on Symfony, that is, a foundation for building and customising a commerce application. That is how its maker describes the project. It is worth considering in an implementation analysis when non-standard logic is a permanent part of the business and will keep evolving.

One example is a customer organisation with many accounts, branch budgets and several levels of approval. Another might be a cart that turns into a quote, which is then negotiated and approved. In such a project you need to describe the process states, the permissions and the events that change them. A clear model of these rules makes it easier to assess future changes.

This doesn’t mean that all B2B features are available out of the box in the free edition. The Sylius Plus offer includes commercial extensions, including the B2B Suite and request-for-quote handling. The quote has to show what comes from the base, what from the paid package and what will be written. Features and licence terms need to be confirmed for the chosen option.

More freedom also means more decisions on the team’s side. You need to plan content management, integrations, the staff interface and deployments. Don’t compare a standard PrestaShop installation with an unlimited set of possibilities that have yet to be built in Sylius. Compare two ready-to-deliver proposals with the same scope.

ERP integration: where the final price is set

First choose the source of truth for product, stock, price and credit limit. It doesn’t have to be the same system for every kind of data, but responsibility must be unambiguous. If the ERP sets the trade terms, the store shouldn’t quietly add competing rules that the sales department can’t explain afterwards.

Decide how things should behave when the integration is unavailable. Can the last known price be shown? How long is it valid? Can an order be accepted, or only an enquiry? What will the customer see if the limit changed between opening the cart and confirming it? The answers should go into the requirements and the tests for both options.

Also check retries. If the connection drops after the order has been saved in the ERP, a retry shouldn’t create a second document. You need identifiers, logs and a way of reconciling state. A ready-made integration module is worth judging on precisely these situations, not just on successfully sending a single product.

Costs that only show up during development

Compare the cost of launch and the following three years. Include licences, hosting, maintenance, updates, monitoring and planned changes. Add the time of employees handling exceptions manually. If one option doesn’t support a needed process, its lower quote doesn’t yet describe the cost of running the business.

In PrestaShop part of the work may come down to configuring and adapting modules. In Sylius custom code or commercial packages may play a bigger role. That doesn’t mean there is a fixed price difference for every project. Check specific offers, the scope of testing and the availability of people who will maintain the implementation.

Ask for a quote for two changes you expect after launch. It might be a new type of discount and a second stage of order approval. The point isn’t a guaranteed price for many years, but checking which areas will need rebuilding. An architecture that works well for the first launch may turn out to be difficult for the planned direction of development.

Take into account the project being taken over by another team. Documentation, readable code, tests of the rules and repeatable deployment are valuable on both platforms. The popularity of a technology alone doesn’t provide a replacement if all the knowledge about prices and integrations sits with one person.

Does B2B need headless

Headless means separating the layer the customer uses from the system that handles commerce. It can make sense when the same processes have to feed several interfaces or when front-end development needs a high degree of independence. The need should, however, be described by a specific use case.

A separate front end adds areas to maintain: login, session, cart, error handling, analytics and interface compatibility. It doesn’t automatically speed up price calculation in the ERP. If the only justification is a modern look, also compare a solution without splitting the application. The graphic design doesn’t dictate the architecture.

A third option: improve the current store

When the problem is inconsistent rules or a slow import, start by putting them in order. A migration won’t decide for the company which price list applies and who approves exceptions. First describe the process, remove the contradictions and check whether the current platform really is the obstacle.

You can also extract a selected area, for example price calculation, without replacing the whole store at once. This approach needs its own analysis of availability and data consistency, but it lets you separate a specific problem from a full migration. Compare its cost with cleaning up the modules and with changing platforms.

How to run the comparison

1. Write down the purchasing processes, customer roles and trade rules.
2. Separate the requirements that are mandatory at launch from later development.
3. Prepare sample data and orders that show the difficult cases.
4. Get quotes for both options against the same list of requirements.
5. Check a prototype of the riskiest process.
6. Compare maintenance costs, limitations and the ability to change contractors.

For each requirement, note how it will be delivered and what hasn’t been checked yet. Such a table shows the risk far more clearly than a long list of “yes” marks next to features. To assess the answers, use the guide on how to read an e-commerce agency’s offer.

Frequently asked questions

Is Sylius more expensive to maintain?

That can’t be settled without the project scope. Custom code and licences generate costs, but so does maintaining many conflicting modifications. Compare specific processes and the development plan.

Can PrestaShop handle individual prices for hundreds of business customers?

The number of customers alone doesn’t rule this platform out. Check how prices are stored, the data volume and how often it is updated. You need a test of imports and purchases on a representative catalogue.

What about ERP integration on both platforms?

Assess the ready-made connection or the scope of building your own. What matters most are the data supported, errors, retries and responsibility for maintenance. The platform’s name doesn’t replace these arrangements.

Is headless necessary for B2B?

It isn’t a condition for selling to businesses. It is worth considering when there is a justified need for separate interfaces and independent development. In other cases it may increase the scope without solving the main problem.

If the decision depends on a few non-standard rules, start by describing them and building a prototype. As part of e-commerce consulting you can compare the options before a full implementation begins.

Artykuł PrestaShop vs Sylius for B2B sales pochodzi z serwisu eCommerce Expert.

What version 9 changes

Moving from 8 to 9 also affects the technologies the store runs on. PrestaShop 9.0 moved from Symfony 4.4 to Symfony 6.4. This change matters mainly to module authors and to people maintaining custom modifications. Code that uses older mechanisms may need adapting, even if the feature is meant to look identical to the customer. The scope of the changes is described in the PrestaShop 9.0 change documentation.

Check the server requirements for the specific release you plan to deploy. “Our hosting supports PrestaShop” is too general. You need a compatible PHP version, the right extensions, a database and enough resources to run imports and background tasks. The reference point is the official requirements table. Check separately the PHP serving the site and the PHP run by the task scheduler.

For a store owner, what matters is the result: being able to keep maintaining the system, the availability of the extensions you need and your sales processes working. Don’t assume the upgrade will by itself speed up the catalogue, fix search or simplify warehouse work. Such effects need a separate diagnosis and measurements before and after the change.

The biggest unknowns are often modules and the theme

In a standard installation, the scope of work is relatively easy to estimate. In a store developed over several years, the list of modules doesn’t yet tell you what really needs to be carried over. A payment module may have received a local patch, the theme may use a modified cart, and the ERP integration may reach straight into the database. Each such element has to be identified before quoting.

A vendor’s compatibility statement is a good start, but it applies to a specific version of their product. Check whether your licence covers access to that release and whether the update will keep your configuration. If someone has changed a module’s files, downloading a new package may wipe out those modifications. Custom code has to be compared with the original to decide which differences are still needed.

The theme needs a trial too. The home page may look fine while choosing a product combination, address validation or mobile payment stops working. With a bespoke theme you need the sources and instructions for building the files. With a ready-made theme, what matters is the availability of updates and the compatibility of the add-ons bundled with it.

How to check where you stand

Before discussing a date, prepare an inventory. For each extension, record its name, version, vendor, business function and the person responsible for maintaining it. Add information about the licence and any changes. A module nobody can describe needs checking: it may be redundant, but it may also be sending orders to the warehouse once a day.

• Establish the exact version of the store, PHP, database and theme.
• Collect a list of active modules, scheduled tasks and connections to external systems.
• Check overrides and direct changes to core files.
• Verify access to the code, backups and extension vendors’ accounts.
• Describe any unusual rules for prices, delivery, discounts and order handling.

The result should be a document that sorts elements into ready to move, needing a fix, needing a replacement or to be removed. For every unknown you need a way to resolve it. If the store has many overrides, a separate review of overrides in PrestaShop will help. Without this work, an “upgrade” may hide a rebuild of several important features.

When it’s worth postponing

Deploying just before your most important sales campaign increases the cost of any mistake. If there is no urgent security reason, it is wiser to prepare and test the change earlier and schedule the switchover outside the peak. A postponement should, however, have a specific date and conditions to be met by then.

The second reason is the incompatibility of a feature essential to sales. If the payment provider or the integration passing orders to the ERP doesn’t work, running the store on a new core achieves little. First you need a fix, a replacement or an agreed interim procedure. Don’t assume the vendor will be ready in time until you have a version you can test.

It is also worth combining work if the company is already preparing a theme change or a migration to another platform. Adapting a part that is about to be removed can be an unnecessary cost. The condition for such a decision is being able to keep the current store safely maintained until the next implementation.

When delay makes the store harder to maintain

Postponing an upgrade doesn’t stop other suppliers from changing. The host updates the environment, the payment provider changes its integration and the module vendor releases new versions. If the store needs more and more exceptions, every new feature first has to be adapted to old limitations. That effort should appear in the cost comparison.

Check the current support status of the release you use and its dependencies. The availability of security patches doesn’t follow from the store still taking orders. When a security issue appears, the decision on timing has to be based on its significance for the installation and the available safeguards, not only on the campaign calendar.

Compare two options over the same period: cleaning up and upgrading now, versus continued maintenance with a later move. In the second option, include compatibility fixes, extra testing and work that will have to be done again later. Such a comparison gives a better basis for a decision than the belief that a working store should never be touched.

How to prepare a safe upgrade

Start with a backup of the files and database, and a test restore. Then set up a separate test environment. Block access for outsiders and indexing, disable emails to customers, and switch payments and integrations to the appropriate test mode. A copy of production must not accidentally create real shipments or pass on duplicate orders.

On the copy, run the full upgrade and write down every extra step. Test the processes: guest and logged-in purchase, product combinations, discounts, delivery, payments, provider confirmations, emails and export to the ERP. Also check order cancellation and refunds. Ask a customer service employee to do their usual tasks, because not every exception is visible in the documentation.

Before the switchover, decide when writes will be paused, a fresh backup made and the new version launched. Agree who decides on a rollback and how payments coming in during that time will be reconciled. Returning to the old database after accepting new orders requires those orders to be secured and the data reconciled. Restoring the files alone doesn’t solve that problem.

Before approving the deployment, it is also worth agreeing how it will be signed off. Prepare a table with the test name, expected result, the person checking it and its status. If a case failed, describe its impact on sales. A minor visual difference and incorrect price calculation should not carry the same weight. Make the go-live decision based on this list, not on the tool’s message that the upgrade finished without errors. Keep the trial results with the project documentation so the next contractor knows what was actually verified and which limitations the company accepted.

Frequently asked questions

Can the store be upgraded without downtime?

Most of the preparation can be done while sales continue as normal. The switchover itself may require briefly pausing orders to keep the data consistent. A promise of zero downtime requires a specific technical solution and a rehearsal of the whole procedure.

What about modules the vendor no longer develops?

First check whether their function is still needed. If it is, you need to find a replacement or commission an adaptation of the code, taking the licence into account. In both cases, agree who will be responsible for fixes later.

Will the upgrade affect my Google rankings?

The version number itself guarantees neither an improvement nor a drop in visibility. Check URLs, content, canonical links, indexing and server responses before and after deployment. If you are also changing the URL structure, you need a separate redirect plan.

How long does a major version upgrade take?

The time depends mainly on the compatibility of extensions, the amount of custom code and the number of processes to test. A reliable date comes after the inventory and a trial on a copy. The time it takes to run the upgrade tool is only part of the work.

Where to start the decision

Ask your contractor for a list of obstacles, a test plan and a switchover procedure. Only on that basis should you approve the budget and the date. If you need help defining the scope, see store migrations and upgrades.

Artykuł PrestaShop 8 or 9: when to upgrade and when to wait pochodzi z serwisu eCommerce Expert.

Start with the work the store has to do

Comparing platforms only makes sense once sales have been described. A store with a few hundred products may have a complex configurator, while a catalogue of thousands of items may rely on a simple single-item purchase. In the first case the difficulty lies in the product logic, in the second perhaps in data import and search. The label “small store” hides these differences.

Prepare examples of real orders and show what happens to them after purchase. Who enters the product? Where does the stock level come from? Where is the invoice created? What does customer service do when a customer changes their address or orders an item that isn’t immediately available? The platform should fit these answers, not just the look of the site.

• Are how-to content and campaign pages an important part of daily work?
• What types of products, variants and pricing rules does the catalogue have?
• Which systems must the store exchange data with, and how quickly?
• Who will deploy updates and fix failures?
• What budget can the company allocate to maintenance after launch?

On that basis, choose a few scenarios to demonstrate. Ask contractors for both options to show the same process on similar data. That tells you far more about how useful a solution is than comparing feature lists on vendors’ websites.

Catalogue and product variants

Both platforms support products with variants. In practice you need to check how it is to work with your particular catalogue: how many combinations there are, how prices change, where images live and how stock is updated. For the team managing the product range, the time needed to correct a whole group of products may matter more than the mere existence of a feature.

WooCommerce provides a built-in CSV product import and export, including variable products. The scope and format of the data are described in the importer documentation. This is useful for a standard catalogue, but it doesn’t mean the fields of every additional extension are handled automatically. If a product has configuration saved by a plugin, check it separately.

Don’t accept an arbitrary threshold beyond which WooCommerce stops working and PrestaShop becomes mandatory. Performance also depends on database queries, filters, extension code, caching and infrastructure. Run a trial on representative data, covering search, filtering and import under traffic. An empty installation with a few products won’t answer questions about the target store.

Cost: implementation, extensions and maintenance

When comparing options based on open-source software, the price of the platform itself is just one item. Put analysis, theme, configuration, integrations, data migration, testing and training into the budget. Separately count hosting, updates, backups, paid extensions and support time. If you are considering a managed or subscription offer, check exactly what its price covers.

The same feature name can hide a very different scope. “Warehouse integration” can mean a manual file export or two-way synchronisation with error handling. A quote for a ready-made plugin isn’t comparable with building such a process from scratch. In both offers, ask for a description of update frequency, responsibility for failures and behaviour when the other system is unavailable.

Prepare a three-year cost: launch, expected licence renewals, maintenance and agreed development work. Add the time of employees doing manual tasks that a given option doesn’t automate. A cheap start can be a good choice if the scope is simple. It should, however, come from a deliberate limitation of features, not from leaving out the cost of running the store later.

B2B sales and price lists

“Supports B2B” needs clarifying. A discount for a customer group, a price agreed for a specific account, a credit limit and an order approved by a manager are different features. Write them down separately. For each, state whether it will be handled by the platform, an extension, custom code or the ERP.

First establish where the final price is created. If the ERP calculates individual terms, the store should receive an unambiguous result or apply agreed rules. Calculating discounts in parallel in several modules makes control difficult. A test covering a product on promotion, a customer discount and a quantity threshold will show more than a demo of a single price list.

Also ask for a demonstration of a change in trade terms. Check when the new price appears in the catalogue, what happens to an open cart and how the order is saved. If the purchase process involves multiple roles, negotiation or non-standard approval rules, broaden the analysis. Such a case is covered in the comparison of PrestaShop and Sylius for B2B.

Maintenance and updates

With WooCommerce you also maintain WordPress, the theme and the site’s other plugins. With PrestaShop the dependencies include the core, the theme, modules and custom modifications. In both cases what matters is the compatibility of the whole set. It isn’t enough that a single extension is on its latest version if that update doesn’t work with the rest of the store.

Agree the way of working when you choose the platform: a test environment, an update schedule, a test order and a rollback procedure. Check whether backups are stored off the server itself and whether someone can restore them. These tasks need to be included in the offer, even if the store looks trouble-free on launch day.

The ability to change contractors also matters. Your own service accounts, repository access and integration documentation make it easier to take over the project. The availability of many specialists for a given platform won’t help if nobody receives the sources of the modified theme or a description of the deployment process.

Which option fits your company

If you have a substantial WordPress site, regularly publish guides and want to add standard sales, WooCommerce should be on your shortlist. One admin panel can simplify the editorial team’s work. The condition is checking whether the current theme and plugins are also suitable for running a store.

If you are building a site primarily around commerce and the team works daily with products, deliveries and orders, test PrestaShop on your own scenarios. Assess the availability of the specific integrations and how convenient the admin panel is for staff. A platform’s intended purpose doesn’t replace a demonstration of the features you need.

For standard sales and no one responsible for technical maintenance, it is worth comparing SaaS too. A subscription can simplify some duties, but you need to check integration limits, data export options and the total fees. If the company has a very unusual process, comparing only two popular platforms may, on the other hand, narrow the choice too much.

A table for comparing offers

Frequently asked questions

Can a store be moved from WooCommerce to PrestaShop?

Yes, but the migration requires mapping data, features and URLs. A product import doesn’t automatically move the whole store. The detailed scope is described in the article on migrating from WooCommerce to PrestaShop.

Which platform is faster?

Without measuring a specific implementation there is no honest answer. Compare the same scenarios, data size and load. A home page test result isn’t enough to assess filters and the cart.

What about the cost of plugins and modules over longer-term maintenance?

Collect the renewal terms, scope of support and update costs for each paid add-on. Add the work needed when changing supplier or losing compatibility. The bill for the first purchase doesn’t show the whole cost.

Does the choice of platform affect SEO?

It affects how changes are implemented, but it doesn’t replace good content and correct configuration. In both options check URLs, indexing, speed and the ability to edit metadata. When changing platforms, existing URLs need a dedicated plan.

If both offers look similar, commission a demonstration of the hardest process on your own data. The result of that trial can settle the choice before a bigger spend. E-commerce consulting will help you put the requirements in order.

Artykuł PrestaShop vs WooCommerce: which platform to choose pochodzi z serwisu eCommerce Expert.

Before you change anything

Establish the scope of the failure. Does no page open at all, only the admin panel, or a specific checkout step? Check one example without logging in and another on a test account. Note the product used, the delivery method and the action that preceded the error. If the problem concerns payments, don’t repeat purchases blindly: first check whether the provider has already taken the money.

Write down recent changes. A module update, a PHP switch, a theme deployment, a product import and a change of hosting settings are all different leads. The time of the report doesn’t have to be the time the failure started. Compare it with the last successful orders and the logs, so you don’t blame the problem on a change made after it had already appeared.

Before intervening, make a backup of the database and files or ask your host to secure the current state. Don’t overwrite the last working backup. The database from the time of the failure may contain orders and payments that aren’t in yesterday’s backup. If disk space is short, creating a large archive on the same server may make things worse. In that case agree another way of making the backup with the administrator.

Where to look for logs

You may need the web server, PHP and application logs. On shared hosting, start with the logs section of the control panel. If you don’t have access to them, give support the exact URL, the time including the time zone and a description of what you did. A request saying “the store doesn’t work” leaves far more room for guesswork.

On a VPS the location depends on the Apache or nginx configuration, PHP-FPM and how the store is run. In a container environment some logs may go to the process output rather than a separate file. In a PrestaShop installation, also check the application log directory, usually within var/logs, depending on the version and configuration. No entry in one place doesn’t mean there was no error.

Look for the event that matches the time of the attempt. Read the first relevant exception and its surroundings, not just the last line. A missing class message may result from an incomplete deployment, and a database connection error from the database being unavailable. Keep the original excerpt for analysis. Before sharing it outside the authorised team, remove passwords, tokens and customer data.

Debug mode: how to use it

If the admin panel works, debug mode can be enabled in the performance settings under advanced parameters. Without access to the panel, the PrestaShop documentation describes changing the _PS_MODE_DEV_ constant in config/defines.inc.php. Change the existing definition instead of adding a second one. The configuration is described in the official debugging guide.

Do this on a secured copy or in an environment with restricted access. A detailed message can reveal paths, queries and configuration details. Debug mode isn’t a fix: it helps you see the cause. Once you have recorded the data you need, turn it off and check how the store behaves in normal mode.

If the error occurs before PHP or the application starts, PrestaShop’s debug mode won’t show anything. In that case you need to go back to the server logs and the hosting configuration. Don’t keep piling up changes just because you still see the same generic message on screen.

How to tell common causes apart

PHP out of memory

A message containing Allowed memory size exhausted indicates that the process exceeded its memory limit. Find out which action caused it. Importing a large file and an infinite loop in a module need different solutions. Raising the limit may be justified, but only after checking usage and the server’s available resources.

Incompatible PHP version or extension

If the failure started after an environment change, compare the PHP version with the requirements of the exact release of the store and its modules. A syntax error, a missing function or an incompatible method declaration are clues for further analysis. Restoring the previous configuration can help isolate the change, but ultimately you need a supported and compatible combination of software.

A module, an override or an incomplete deployment

A path to an extension in the stack trace shows where the error occurred, but not always its source. Check that the files and dependencies are complete and what changed last. When the message concerns an overridden method, look at the overrides. Simply copying a missing file from a random version can introduce another incompatibility.

Cache and permissions

An error writing or creating a file may result from the wrong directory owner after a deployment. Check the PHP process user and the required permissions. Don’t set 777 across the whole store. If stale cache files are the cause, rebuild them according to the procedure for your version, after keeping the logs needed for the diagnosis.

No disk space or an unavailable database

Check disk space and the file count limit. A full disk can prevent writing sessions, cache and logs, so the absence of a new message can itself be a symptom. For database connection errors, verify its availability and connection limits. Don’t run table repairs or change login credentials without confirming the cause.

When the error appeared after an update

Stop further deployments and compare the state before the change with the current one. Check the package version, whether the files are complete and whether the update changed the database. Rolling back only the code may not be enough if the new version transformed the data. The rollback plan has to cover both.

If the logs point to one module, disable it in a controlled way and repeat exactly the same test. In versions that provide the relevant command, you can use the PrestaShop console; check the syntax in the help of the installed release. If the application cannot start, the console may not work either. Then you need to analyse the files, dependencies and module registration.

Renaming a module’s directory isn’t a universal equivalent of disabling it. It can leave references to classes and configuration behind. Don’t delete the module’s tables either: they may store data needed to settle orders. After the fix, check not only the page that returned the error but also a purchase, payment confirmation and handing the order over for fulfilment.

When to stop trying on your own

Hand the diagnosis over to a technical person when the problem concerns order data, a suspected breach, database corruption or an update you can’t safely roll back. Do the same if you have no working backup and each further step changes the production state. More random fixes make it harder to establish the cause later.

Prepare a short report: store and PHP versions, the scope of the failure, when it occurred, recent changes, an example URL and a log excerpt. Add what has already been done, even if it didn’t help. Share access through a secure channel, using a separate account with the scope needed for the work.

Once the cause is removed, write a short note: what stopped working, which message confirmed the diagnosis, what was changed and how the fix was checked. Include whether orders from the time of the failure need handling. Such a record will help with the next report and let you see whether the problem comes back. If the failure revealed missing monitoring of a particular payment or integration, add the appropriate check to the maintenance procedure.

Frequently asked questions

Does a 500 error mean data loss?

No. It tells you a request wasn’t handled successfully, not what state all the data is in. The operation may, however, have partly completed, so before retrying a payment or an import you need to check the result on both sides of the integration.

How do I disable a module without access to the admin panel?

If your version provides a working console command, use it after checking the help. When starting the application ends in an error, what to do depends on the cause. Don’t use a random SQL query found for a different release.

Why does the store work but the admin panel doesn’t?

The admin panel and the customer-facing part run different pieces of code. The failure may concern an admin module, a specific view or permissions. Check the logs for the attempt to open the panel separately.

Can I restore a backup myself?

Yes, if you know the procedure and which data will be replaced. First secure the current state and any orders created after the backup date. The files, the database and any environment changes must match each other.

The most useful first step is to find the specific error in the log and link it to an action in the store. If you need support with the diagnosis, use troubleshooting help and include the information you have prepared.

Artykuł 500 error in PrestaShop: how to find the cause pochodzi z serwisu eCommerce Expert.

What an override actually is

This article is about overriding classes and controllers, not about changing the look of a template. This mechanism lets you replace or extend a piece of PrestaShop’s standard logic. From a store owner’s point of view it means that some operations may work differently than in a clean installation: for example price calculation or the condition that makes a delivery method available.

A hook is an extension point that a module attaches its own behaviour to. An override reaches into existing behaviour more directly. A module, in turn, is a way of delivering a feature and can use various mechanisms, including overrides. So the statement “we did everything in a module” doesn’t answer the question of how deep the intervention goes.

The PrestaShop documentation points out the limitations and the risk of conflicts between overrides, and describes alternative ways of extending the system. The choice depends on the place in the code and the mechanisms available in a given version. The reference point is the official description of overrides. The practical conclusion: before overriding, check whether the same goal can be achieved through a provided extension point.

Why an update can expose the problem

Imagine a modification that takes over the calculation of the delivery fee. It was created for a specific version of the store and uses its arguments and the way it processes data. After an update, the core may pass different data, expect a different type of result or run an extra check earlier. The custom code still assumes the old flow.

This doesn’t always mean a blank page. The store may keep taking orders but calculate a discount differently for a selected group or skip a condition for a particular delivery method. The error only shows up with a specific cart. That is why a test that consists of opening the home page isn’t enough to confirm compatibility.

Copying an entire core method and adding a small change to it needs particular attention. Such a solution may also preserve old logic that the project later fixed. When updating, you have to compare not only what was added but also what changed in the original. The bigger the copy, the more behaviour has to be reassessed.

When an override may be justified

Sometimes the feature you need concerns a place for which the given version provides no suitable extension point. A limited override can then be a sensible choice if the alternative requires a much larger rebuild. This decision must, however, be documented and taken into account in later maintenance. The cost doesn’t end on launch day.

The documentation should include the reason for the change, the supported versions, the code owner and examples of the expected behaviour. You also need information about the alternatives considered. “The client needed a different price” is not enough. “For a customer with contract A, when ordering a full pack, the ERP price applies” lets you prepare a test.

Agree on the condition for removing the override. It may be the arrival of a suitable hook, a module replacement or dropping the feature. Without such a review, temporary code stays for years. Each next person treats it as essential because nobody is sure what will happen once it is switched off.

How to check what is in your store

The review covers the override directory, module code and a comparison of core files with the original release. Directly editing a core file is a separate kind of modification; it doesn’t have to appear on the list of overrides. That is why an empty overrides directory is no proof that the store is still standard.

Ask the developer for a summary that is also understandable to the person responsible for sales. For each change you should be able to see the business function, the place in the code, the source and how to verify it. A class name on its own won’t help you decide whether the modification can be dropped at the next update.

• Which customer or staff action does this piece change?
• Does it come from a module, or was it written for this store?
• Is it used, and on what data can that be confirmed?
• Does another add-on interfere with the same area?
• Which tests will show that the feature works after the update?

Compare against exactly the release that is installed, not any PrestaShop package. Generated files, configuration and store data need separate treatment. When taking over a project, the repository history and older deployment packages help. If they are missing, you need to state clearly which findings could not be confirmed.

How to clean up existing modifications

The first step is to establish the current behaviour. Record sample carts, prices and delivery conditions before changing any code. For rules that affect billing, prepare expected results agreed with the person responsible for sales. An automated test without the correct business answer may only lock in the existing error.

Next, check which features are still needed. Some may have been replaced by a new version of the platform or a module. Others may concern an unused delivery method or a finished promotion. Removing an unnecessary modification can be simpler than rewriting it, but it also requires a trial on a copy and a dependency check.

For the remaining changes, choose how to implement them: an available hook, a service, decoration where the architecture allows it, or a still-maintained override. Moving code to another file isn’t enough if it keeps the same assumptions about the core’s internals. The goal is to reduce dependencies and make testing easier.

Work in stages. First reproduce the behaviour of one feature, compare the results and only then move on. Replacing price lists, the cart and integrations all at once makes it hard to find the source of differences. If the store update is urgent, separate the necessary adaptation from larger clean-up work that can wait for a separate date.

How to test a change before deployment

Test the edge cases, not just the simplest purchase. If the modification concerns a discount, include a reduced product, several items, different customer groups and changing the quantity in the cart. For delivery, check the free shipping threshold, products with different restrictions and changing the address. The list should follow from the rule that was actually changed.

Also compare the saved data: the order total, the values passed to the payment provider and the document sent to the ERP. A correct amount displayed on the page doesn’t guarantee that every system received the same. Record the results together with the code version so the test can be repeated later.

After deployment, watch the area affected by the change. Agree which discrepancies need an immediate response and who checks them. If a 500 error occurs, keep the log and the test data. With a silent pricing error, value comparisons will matter more than monitoring page availability.

How not to be back here in a year

Write into the terms of cooperation an obligation to document core changes and overrides at every acceptance. A change should come with sources, a rationale and a test. Repository access lets you check what was actually deployed, but on its own it doesn’t replace code review.

At the next update, go back to the register of modifications. Check whether the new release offers a simpler solution and whether the feature still has an owner on the business side. Keeping a short, up-to-date list of dependencies is cheaper than reconstructing them during an outage.

Hand this register over together with the code whenever you change contractors and when planning a store update.

Frequently asked questions

Is an override always a mistake?

No. It can address a need for which there is no suitable extension mechanism. It must, however, be a deliberate decision with documentation and a maintenance plan.

How can I tell whether the store has core changes?

Compare its code with the original package of the same release and the deployment history. The admin panel alone won’t show the full picture. Assessing the differences is best left to someone who knows the project structure.

How much does it cost to clean up overrides?

The number of files isn’t a good basis for a quote. One price list change may take more work than several simple overrides. You need a description of the features, dependencies and test cases.

Does this affect the store’s security?

It can, if custom logic bypasses permission checks or validation, or preserves a piece of code that needed a fix. The mere existence of an override doesn’t prove a vulnerability. The specific implementation is what gets assessed.

Before a planned PrestaShop update, collect a list of changes and what they are for. If nobody knows what was overridden, start with a technical audit that translates the code into a scope of work and a risk to sales.

Artykuł Overrides in PrestaShop: why they break updates pochodzi z serwisu eCommerce Expert.

Compare the same scope

One agency may quote for configuring a ready-made theme, another for designing views and implementing them. Both items are often called “graphic design”. Similarly, “ERP integration” can mean setting up an existing add-on or building synchronisation with exception handling. At that point the price difference tells you nothing yet about value for money.

Prepare a shared table of requirements. For each item, ask for it to be marked: included, out of scope, optional or needs analysis. Add an outcome that can be checked. Instead of “discount handling”, write down a sample cart and the price calculation rules. Instead of “migration”, list products, customers, orders, images, content and URLs.

Also check the obligations on your side. Who provides descriptions and photos? Who cleans the product data? Who approves the redirect map? If the contractor expects to receive finished materials while the company expects them to be prepared as part of the price, the schedule stops being credible before work even starts.

Code rights, licences and project access

Separate three issues: the ability to use the software, access to its sources and the right to have someone else make changes. These are different questions. The store may work correctly, and yet its owner may lack deployment instructions, the module vendor account or the sources needed to rebuild the theme.

Ask for a list of the contractor’s own elements, code created to order and third-party components. Each should come with a description of the terms of use, updates and handover. Don’t assume that paying the invoice automatically settles all rights. The rules for transferring rights and licences follow from the contract and the law – in Poland, the Copyright and Related Rights Act. It is worth having the clauses for your specific project checked by a lawyer.

Organisationally, the domain, hosting, payment and analytics accounts should stay under the company’s control. The contractor can get their own access. Also agree on repository access, how often the code is handed over and how documentation is stored. Your ability to take delivery of the project shouldn’t depend on whether the same developer is still working on it a year from now.

How changes will be billed

A fixed price makes spending easier to plan if the scope and assumptions are well described. Hourly billing gives more freedom when requirements are still being discovered, but it needs transparent reporting and limits. A mixed model can combine quoted stages with a separate budget for tasks that can’t yet be precisely defined.

Ask what happens when a new need comes up. There should be a point where the impact on price and deadline is assessed, and a person who approves the change. The contractor shouldn’t learn about approval from an ambiguous conversation, and the client shouldn’t learn about the cost only from the invoice. Also agree how the used and remaining budget will be reported.

Separate fixing a mismatch with an agreed requirement from extending a feature. For example: if an accepted scenario provides for a discount above a threshold, calculating it incorrectly needs fixing. Adding a different threshold for a new customer group may be a change of scope. A well-described acceptance example helps settle such situations without arguing over what “discount” means.

What exactly “done” means

Acceptance should be based on checkable scenarios. The customer adds a product, chooses a variant, places an order, pays, receives a message, and the order reaches the fulfilment system. The provider’s confirmation must be saved correctly. A screenshot of the cart doesn’t prove this process works.

Require a description of how mobile devices, integrations and exceptional situations will be tested. What happens when a payment is interrupted? How will the store handle a temporary loss of connection to the ERP? Who will see the information about an order that wasn’t passed on? These questions reveal scope that isn’t visible when the best-case scenario is presented.

If the offer includes a performance promise, ask for the measurement conditions: catalogue size, load, server configuration and the views measured. “A fast store” is an opinion, not an acceptance criterion. Also agree who provides the test data, how much time the company has to check a stage and where it reports comments.

At the end of a stage you should have a working result, a list of known limitations and code that matches what was deployed. If the project can’t be run outside its author’s computer, taking it over remains difficult regardless of how good the presentation was.

Support after launch

Separate fixing defects covered by the agreement from ongoing maintenance and further development. Ask how the contractor treats a failure after an external module update or a change in the provider’s API. Not all future problems come from implementation defects. The offer should explain who diagnoses them and on what terms the work is billed.

Response time is not resolution time. Acknowledging a report within an hour doesn’t mean payments are restored within an hour. Agree on support hours, an emergency channel, priority levels and the escalation path. If the store also sells at weekends, check whether the contract provides any support then.

In the maintenance budget include updates, monitoring, backups and restore tests. Find out who keeps track of expiring licences and certificates. Also ask about reporting: it should be clear what work was done, which problems remain and what needs the store owner’s decision.

How the cooperation will end

Agree the terms for handing over the project before signing the contract. You need the sources, up-to-date documentation, a list of services, deployment instructions and a description of the integrations. On top of that come the rules for handing over work that has started but not yet been accepted. The form and effects of terminating the contract need to be checked against its specific clauses.

Check whether time is set aside for the new team’s questions and how much it will cost. Handing over an archive without configuration information may make it impossible to recreate the environment. A good technical criterion is whether a person who hasn’t worked on the project before can get a copy running.

If you are changing contractors right now, a separate checklist is in the article on taking over a store from an agency. It is also worth using when assessing a new offer, before any access problems arise.

Questions you can send to contractors

1. Which features and views does the quoted price include, and which are excluded?
2. Which assumptions still need confirming before the deadline is set?
3. What exactly does each integration cover, and who is responsible for its errors?
4. What data do you migrate, and how will you check the migration is complete?
5. What materials and decisions do you expect from our team?
6. How will a change of scope be priced and approved?
7. Which scenarios will decide acceptance of the store?
8. On what data and devices will you test?
9. Which licences need renewing, and who will own the accounts?
10. What code rights and materials will we receive at the end?
11. What are the support hours and response times for a sales outage?
12. How much does maintenance cost and what does it cover over the following years?
13. What does handing the project over to another contractor look like?

Keep the answers with the final version of the offer. If an important point was agreed in a meeting, ask for it to be added to the document describing the scope. After a few months both sides may remember the conversation differently, and the team delivering the project may not have been involved in the sale. A written example and acceptance criterion reduce this risk.

Frequently asked questions

Does the cheapest offer always mean a smaller scope?

No. The contractor may have a ready solution and experience with a similar process. Still, ask them to confirm the same requirements and maintenance costs before treating the difference as a saving.

What should the agreement on code rights include?

You need to distinguish bespoke code, third-party components, sources and the ability to make further modifications. Agree the scope of rights or licences and when and on what terms you obtain them. A lawyer should check the clause against your specific contract.

Is it worth paying for pre-implementation analysis?

Yes, if it results in requirements, risks and a scope that lets you compare options. Before buying, agree which documents you will receive and whether you can use them when choosing a different contractor.

How do I check an agency’s past projects?

Ask which part of the store shown they were responsible for and when they did the work. With the client’s consent, ask for a conversation about communication, billing for changes and support after launch. The look of a website doesn’t show the quality of the cooperation.

Before you choose, collect the answers in one document and mark the items that remain unclear. If you need an independent assessment of the scope and order of work, see support with store growth decisions.

Artykuł How to evaluate an e-commerce agency’s offer pochodzi z serwisu eCommerce Expert.

Is the migration really needed

A slow store doesn’t necessarily need a new platform. The cause may be inefficient queries, unsuitable hosting or a specific plugin. Outdated stock levels may come from the integration, and wrong prices from inconsistent data. Moving the same rules and data to another system will keep the source of the trouble.

Write the problems down as observable situations. For example: an import blocks work in the admin panel, a price update takes too long, staff manually correct the data of every order. Then compare the cost of fixing the current solution with a migration. In both options there should be a defined outcome and a way of checking it.

A migration is justified if the target system handles the necessary processes better and the benefit outweighs the cost of moving and of later maintenance. Check this with a demonstration of the hardest scenario. The PrestaShop vs WooCommerce comparison will also help you put the criteria in order.

What needs to be inventoried

First create a register of data and features. For each item, state the source, the destination, the transfer method and how it will be checked. Note whether the data is still being changed in the live store. This lets you separate the initial catalogue load from topping up orders and customers just before the switchover.

• Products, variants, SKU and EAN identifiers, prices, stock and relationships between items.
• Categories, brands, attributes, images, attachments and descriptions in each language.
• Customer accounts, addresses, groups and consent information, with its context.
• Orders, line items, discounts, payments, statuses and document numbers.
• Reviews, information pages, blog articles and downloadable materials.
• Coupons, gift cards, loyalty points and extension data, if they are used.

WooCommerce has a built-in CSV product export, described in the importer and exporter documentation. Such a file is a source of product data, not a complete functional copy of the store. Order, customer and extension data need a separate solution and mapping to the PrestaShop structure.

Automate repetitive data transfer, but agree the mapping of fields and exceptions by hand. Check a sample that also includes unusual records: a product without an image, a multi-variant bundle, a customer with several addresses or a partially refunded order. A matching record count doesn’t prove that their meaning has been preserved.

Order history and documents

Decide whether the full history should go into the new admin panel or whether part of it will stay in a secured archive. Either option must let staff find an earlier purchase and resolve a customer’s request. If the old system stays in read-only mode, agree who will maintain it, secure it and give authorised employees access.

Don’t recalculate historical orders using new price lists and current tax rules. The migrated history should keep the values recorded at the time of purchase. Check totals, discounts, delivery costs and links to payments. The order number in the new system may differ from the old one, so you need a permanent mapping between the identifiers.

Documents issued in the previous system should not be treated as new orders to be invoiced again. Agree how the originals can be accessed and the scope of migration with the people responsible for accounting and customer service. Also check that importing the history won’t trigger emails, automations or an export to the ERP again.

URLs and Google visibility

Before the move, collect URLs from the sitemap, analytics tools, Search Console and logs. For every important URL, define its new equivalent. Don’t limit yourself to products: traffic may lead to categories, guides and older campaign pages. The list should be ready before the old store stops being available.

Google recommends mapping URLs and using permanent redirects to the corresponding new pages. Redirecting everything to the home page in bulk may be treated as a soft 404. Internal links, canonical tags and sitemaps also need updating. These principles are described in Google’s site move documentation.

Assess filters and pagination separately. Not every technically accessible URL should become a separate landing page. Check which views have content and meaning for the user and which merely duplicate the catalogue. Make indexing decisions deliberately instead of automatically recreating all the old parameters.

Before launch, check a sample and an automated response report for the whole prepared map. A redirect should lead to the right, working page without an unnecessary chain. When URLs change, visibility may fluctuate for a while; there is no guarantee of identical rankings. It is worth limiting simultaneous changes to content and structure so the effects of the move are easier to assess.

Differences an import won’t handle

A product variant must keep its own identifier, stock, price and link to images where they are separate. The name “size” in two systems doesn’t guarantee that the whole structure matches. Also check units, bundles and personalised products. A configuration built with a plugin may need a separate module or a rebuild.

Compare taxes, discounts and delivery costs on the same carts. Pay attention to rounding and the order in which promotions are applied. A matching price for a single product isn’t enough if the discrepancy only appears with several items and a coupon covering part of the order.

Customer accounts and passwords are two different tasks. Moving the email address doesn’t mean the new system will correctly verify the old password hash. Check the actual authentication mechanism of both installations. If a compatible password migration isn’t available, prepare a secure way to set a new password and clear communication. Never export or send passwords in plain text.

The blog can stay on WordPress or be moved to an agreed tool. This decision affects URLs, menus, search and the editorial team’s work. Don’t assume that the store’s target platform will automatically reproduce every feature of the current site.

Sales switchover plan

1. Launch a secured target environment and isolate its payments, email and integrations.
2. Run a trial migration, keeping an error report and an identifier map.
3. Check the data and complete processes together with the people who run the store.
4. Repeat the trial on fresh data and measure the time needed for the final operations.
5. Set the moment when changes and orders are paused, and how payments in progress will be handled.
6. Transfer the remaining data, enable the redirects and run a production test.
7. Confirm that monitoring works and that the team is ready to handle reports.

The rollback plan must state the point up to which a simple return is possible. Once the new store starts taking orders, restoring the old database without reconciling the data may lose them. Agree who will make the decision and how transactions accepted after the switchover will be secured.

The first two weeks after migration

Check payments, order handover, stock updates and customer reports every day. A transaction error needs an immediate response. Don’t wait for a bigger data sample if the provider takes the money and the store doesn’t save the confirmation.

Also watch 404 errors, indexing and traffic on important pages. When comparing conversion, take into account whether the analytics is correct and the traffic sources. A drop in recorded purchases may come from a measurement error, but that has to be confirmed with order data. Keep observations separate from hypotheses and record the fixes you make.

Appoint one person to collect reports after launch. For each one, record the URL, the action, the expected result and the order number if the problem concerns one. With a shared list, customer service and developers won’t be investigating the same case in parallel across several channels.

Frequently asked questions

Will I lose my Google rankings?

Unchanged rankings can’t be guaranteed. A URL map, proper redirects and indexing checks reduce the risk of technical errors. Changes to content or structure need an additional assessment.

Will customers keep their accounts and passwords?

Accounts can be moved once the data mapping is agreed. Keeping passwords depends on the compatibility of the mechanisms and the chosen migration solution. If they aren’t compatible, plan for customers to set new passwords.

How long does a store migration take?

It depends on the data, integrations and functional differences. The timeline should include a trial migration, fixes and testing by staff. The import itself is only one stage.

Does the store have to be offline the whole time?

No. Preparation and most of the trials run in parallel with sales. At the end you need to agree a short period of controlled switchover and a consistent transfer of changes.

Before getting a quote, prepare a list of data, integrations and your hardest orders. It will help define the real scope of the store migration and check whether changing platforms pays off.

Artykuł Migrating from WooCommerce to PrestaShop: what needs to move pochodzi z serwisu eCommerce Expert.

The first 48 hours: access and a backup

Appoint one person to gather information and coordinate changes. If every employee separately asks for a password reset or changes settings, it is easy to lose track. Prepare a register of services: name, account owner, login URL, provider contact, renewal date and who has access. Don’t write passwords in a shared spreadsheet.

Check the domain and DNS, hosting, store admin, database, repository, email, payment providers, courier integrations and the ERP. Include analytics accounts, advertising tools and services that store backups. Store administrator access doesn’t mean server access, and being able to pay for hosting doesn’t necessarily mean control over the domain.

When recovering accounts, use the providers’ official procedures and documents confirming the company’s rights. First check the email addresses and phone numbers used for account recovery. Once the situation is under control, give the new team separate accounts. Plan password and key changes with the services that use them in mind, so you don’t accidentally stop a synchronisation.

Make a backup of the files and database before any bigger changes. Also secure the logs, the scheduled task configuration and the server settings needed to recreate the store. Don’t keep the archive in a public directory of the website. If you have no technical access, ask your host to secure the data within the rights you have.

What you have and what is missing

Separate the working version of the store from the materials needed to develop it. The server may hold PHP files but only built and minified JavaScript and CSS. The theme sources, tool configuration or deployment script may be missing. A server backup is valuable then, but it doesn’t replace a complete project.

Check the repository: does it contain the last deployed version, all custom modules and the change history? Access to an empty or long-outdated repository alone isn’t enough. A comparison with production will show whether fixes were made directly on the server and whether they can be reproduced.

• Collect the bespoke code, theme sources and build instructions.
• Find the list of licences, invoices and extension vendor accounts.
• Secure descriptions of the integrations, scheduled tasks and automated exports.
• Check whether there are instructions for deployment and restoring backups.
• Collect open tickets, accepted requirements and unfinished work.

Where something is missing, record the consequence. Missing module documentation may mean the code needs analysing. Missing sources for part of the interface may force it to be rebuilt. Lacking the right to download an add-on’s updates requires contacting the vendor. Such a description is more useful than a general verdict that the previous agency left a mess.

How to assess the state of the store

The new contractor should first run a copy in an isolated environment. Access has to be restricted, real email sending disabled and automations that create documents or shipments disconnected. Only on such a copy can you test updates and the effect of disabling suspicious modules.

The review covers the platform and PHP versions, extensions, core changes, permissions, backups and how deployments are done. In PrestaShop, overrides need separate attention. The technical list should be tied to sales: which part is responsible for prices, availability, payments and passing on orders.

Check the tasks that run in the background. The store may look fine even though it hasn’t updated stock for a week or isn’t receiving confirmations. For each integration, establish the direction of exchange, frequency, log location and who responds to errors. Pay attention to processes that have so far been run from the previous contractor’s infrastructure.

The takeover report should group the work by consequences: urgent threats to sales and data, necessary maintenance and later development. Each item needs evidence, a proposed outcome and an estimate with its uncertainty marked. The age of the store alone doesn’t justify building a new system.

Formal matters to clarify

Collect the contract, orders, acceptance reports, correspondence and licence documents. Check what was agreed about the code, access to sources, modifications and handover after the end of cooperation. Don’t draw conclusions about rights to the whole project solely from an invoice or from the fact that you use the store.

Third-party components have their own terms. A module bought by the agency may require an account transfer, a change of assigned domain or a new licence; this depends on the vendor’s rules and your arrangements with the contractor. Ask for confirmation for each specific product. A general assurance that “everything is paid for” doesn’t explain access to updates.

If there is a dispute over the code or a refusal to hand over materials, give a lawyer the documents and a precise list of what is missing. In Poland the basic rules are set out in the Copyright and Related Rights Act, but assessing rights requires taking the specific contract into account. Securing the store technically and pursuing claims are separate tasks.

Handing the database over to a new company also requires putting the rules for access to personal data in order. Verify roles, the data processing documentation and how the previous contractor’s access is ended with the person responsible for data protection. Agree what happens to working copies; the obligations related to ending services are covered in the Polish data protection authority’s (UODO) guidance on data processing. Don’t send the full database to several potential contractors just so they can compare quotes.

How to prepare the handover to the new team

Prepare a short document describing how the company and the store work. List the key processes, campaign dates and deployment constraints. Add a few examples of orders with unusual conditions. The person taking over the store needs to know what behaviour to preserve, not just how to run the application.

Organise the materials into four groups: code and deployments, services and access, business processes, and a list of problems. Hand over secrets separately in a password manager. Assign an owner to every access, and once the takeover is complete remove unnecessary permissions and unused keys.

Define a measurable end to the takeover stage. The new team should be able to recreate the store, carry out a controlled deployment, find failure logs and show how to contact the providers. It should also present a list of gaps that haven’t been resolved yet. A takeover doesn’t have to mean fixing all historical problems at once.

How to reduce dependence on the next contractor

Your own accounts and up-to-date documentation should be part of normal work, not a package prepared only when you part ways. Take delivery of the code and a description of changes after each stage. Check that the deployed version is in the repository and that it is known how to recreate it.

Appoint someone on the company side to be responsible for renewal dates and access. Agree on a regular backup restore test and on keeping the list of integrations up to date. Even a good contractor may change their team, end the service or be temporarily unavailable. The store should have a documented way of running in that situation too.

Before a new contract, use the list of questions for an e-commerce agency. Check the terms for handing over the project and handling failures after launch particularly carefully.

Also agree on a contact channel for the takeover period. Employees should know whom to report a missing order, a wrong price or broken shipping to, and what information to include. The new contractor needs a single list of reports with priorities. Without it, it is easy to focus on visible details while a serious integration problem stays buried in private correspondence. After the first review, agree together on the order of fixes and a date for reassessing the state of the store.

Frequently asked questions

The contractor won’t hand over access. What can I do?

Collect the documents, identify the missing accounts and use their providers’ official procedures. In parallel, clarify with a lawyer the obligations arising from the contract. Don’t try to access other people’s accounts outside the authorisation procedure.

Are the modules bought by the agency mine?

It depends on the licence, how they were bought and the contract. Check whether you can use them, update them and transfer their support to another contractor. You need confirmation for each specific extension.

Does the store have to be rebuilt from scratch?

No. First you need to assess whether it can be recreated, maintained and developed. A rebuild may be justified, but it should follow from a comparison of costs and limitations.

How long does taking over a store take?

It depends on access, documentation and the degree of modification. Separate securing current sales from fully understanding the project. The timeline for the second stage can be reliably set after the first review.

If you need help, prepare a list of access details, a description of current problems and information about the latest backup. It is a good starting point for taking over and stabilising the store.

Artykuł Store abandoned by its developer: where to start pochodzi z serwisu eCommerce Expert.

This change affects the whole way projects are delivered. A developer uses their experience differently, an agency has to rethink its pricing, and a client can commission work that previously didn’t fit the budget. Each of these parties, however, has a different job to do.

Experience matters when judging a solution

In my work, defining the task precisely matters more and more. A model needs a description of what the application is supposed to do. If the description is incomplete, the generated code may look correct and still solve a different problem from the one the client came with.

That is why after the code is generated I have to go back to the assumptions and assess the result. This is where I draw on experience from earlier implementations. It helps me recognise a wrong solution before it reaches the store and decide what needs fixing. The speed of writing itself matters less and less in this process.

You can see this in the example of the PrestaShop experts directory I once worked on. Three developers built it over three months. Today I estimate that with current tools I could do the same project alone in a month, including code review. Much of the work back then was repetitive, and that is exactly what is easiest for me to speed up now.

It’s harder to start with simple tasks

This way of working raises the problem of learning the profession. A junior developer used to gain experience on simpler, repetitive tasks. Someone had to do them, and the junior had the chance to write the code themselves and understand how it works.

When a model takes over these tasks, a beginner is expected sooner to assess a finished solution. But that assessment requires knowledge that used to be gained precisely by writing. I don’t yet have a good answer to how this kind of learning should look. What I do see is that the traditional way into the profession needs rethinking.

Pricing has to reflect the new way of working

For years agencies based their quotes on developer hours. They estimated the time needed to complete tasks and multiplied it by a rate. The accuracy of those estimates determined how much was left of the project after costs were covered.

If some tasks can be done several times faster, the old calculations no longer reflect the actual effort. Some agencies lower their prices and take on more work. Others keep their prices, basing their offer more on understanding the client’s needs and taking responsibility for the implementation. There are also contractors who still price projects on the old assumptions.

From the client’s point of view, what counts is an explanation of what the offer includes. How long will it take to understand the needs? How will the code be produced and who will check it? What will the contractor do if a problem appears after launch? The mere statement that AI is used answers none of these questions.

Lower delivery costs open up new possibilities

For a store owner, shorter working time can mean a cheaper module, a warehouse integration or a checkout rebuild. Changes postponed because of cost then become possible within the current budget. It is a very practical result of how these tools have developed.

The saving only makes sense, however, if it covers delivering a working solution together with checking it. Code can be generated quickly without any review too. A module launched after one evening’s work may work until the first platform update or the first unusual order.

I expect to see more and more such cases in audits. Finding the cause of a failure still requires understanding what happened, and it doesn’t get cheaper just because the code itself was written quickly. That is why, when choosing a contractor, I would ask about tests, code review and responsibility for later fixes.

First you need to know what is worth building

Whatever the tools, a store needs a solution that fits the way the company works. The data model has to be designed around its processes. For an ERP integration I still need to talk to the person who knows why the batch number ends up in the notes field. I won’t find that in an example in the documentation.

The same goes for a migration decision. Before I advise changing platforms, rebuilding the store or keeping the current solution, I have to compare the costs of these options. AI helps with doing the work, but without knowledge of the company it won’t choose the right direction for the client.

That is exactly why conversations, decisions and assessing results take up more of my work today. I can build a solution faster, so I want all the more to establish first whether the client really needs it and whether the cost of building it is justified.

Artykuł AI is changing our world pochodzi z serwisu eCommerce Expert.

I come back to this project because it shows well how my work has changed. I know its scope and I remember what we spent our time on. So I can compare specific tasks with how I would approach them now.

A simple directory, a lot of work underneath

The PrestaShop experts directory is a catalogue of certified agencies. A store owner browses their profiles, checks their specialisations and references, and then contacts the chosen contractor. Agencies manage their profiles and take care of how they present themselves against the competition.

From a visitor’s point of view the principle is simple. When building it, though, every stage needs attention: data entry, validation, search and presentation of results. A filter selected on the page must match the parameters in the URL and the database query. A form should accept valid data and catch invalid data. Everything has to work across different language versions.

On top of that comes the admin panel. The directory’s users never see it, but building it took as much work as the public part. These are the tasks that filled week after week for us: necessary, often repetitive, and each one requiring code to be written and checked.

Three people also meant time spent on collaboration

Splitting the tasks let us work in parallel, but it required daily coordination. We waited for code reviews, agreed on solutions and merged changes made in different parts of the application. In the schedule this collaboration looked smaller than it later turned out to be in practice.

That is why three months of work by three people is much more than just writing features. That time also included everything needed to turn separate pieces into one working application.

What the work would look like today

Over recent months I have built myself a set of tools based on language models. I hand a large part of repetitive programming work over to them. For a directory like this I would start by describing the data structure and the rules of operation, and then use that to create the application skeleton, migrations and the admin panel.

These are tasks where today I think in days rather than weeks. The same goes for forms, validation and language versions: a shared description lets me generate related pieces that previously had to be written separately. My job then is to check whether the result matches the assumptions. Places where the solution departs from the typical pattern need particular attention.

The place of testing in the whole process has changed too. Tests used to be left until the end, if there was time, and there rarely was. Now they are written together with the code. I can move straight on to review without waiting for a second developer to finish their task.

Hence my estimate: one month of solo work instead of nine person-months. A large part of that earlier effort went into activities that tools now handle. Working alone also removes the time needed to coordinate three people.

What I account for in that month

I would still need to talk to the people who will use the directory. To agree what an agency profile contains, who can edit it and how search works. The country filter is a good example. Should it indicate where the agency is based, or the market it serves? Both options can be programmed. The choice depends on how a store owner looks for a contractor.

A model can suggest an answer, but without knowing users’ needs it is easy to make a wrong assumption. Writing code faster doesn’t relieve me of making that decision.

In the estimated month I also include reading and checking the generated code. It needs at least as much attention as code written by hand. A solution that looks finished can lull you into a false sense of security, and I am still the one responsible for how it works.

What this comparison says about project pricing

That month is my assessment of a specific project that I know. It shows how much the contractor’s way of working matters to the cost of an implementation. For years we mainly counted the time developers needed to write a solution. Today, for repetitive tasks, that effort can be much smaller.

If you are commissioning a similar panel, ask the contractor to explain what they will spend the quoted time on. How do they use AI? How much work do they plan for defining requirements, and how much for checking the result? You will learn more from that conversation than from the number of hours alone.

This comparison also led me to take a broader look at my profession and how implementations are billed. I write about it in the article AI is changing our world.

Artykuł The project we had three months for pochodzi z serwisu eCommerce Expert.