For software houses and e-commerce agencies

PrestaShop isn't just another PHP framework.

You have your own developers, but the PrestaShop project is stuck on something the documentation doesn't make obvious: multistore, stock levels, or the differences between versions. I step in as a PrestaShop specialist on a specific problem, whether that's a consultation, a second opinion, a code review, or the hardest part of the task.

Scope

Why a team would bring someone in from outside

The case the team is stuck on

A bug that comes back after every fix, stock levels that drift out of sync, a module that broke after an update. I dig into the PrestaShop core and the database until I find where it's happening.

A second opinion before a decision

Override or module, a core change or a workaround, upgrade now or later. I tell you what I'd do and what each path will cost to maintain.

Code review with PrestaShop in mind

I check your developers' changes before they reach production: overrides instead of edits to core files, separate tables instead of new columns in the store's own tables, native classes instead of raw SQL.

Environments and deployments

Dev, staging and production with automatic deployment from GitHub: a webhook, a post-merge hook that clears the cache, and both the repository and the test environments locked down. That's the setup I run for mierzymy.pl and sklep.dayspashe.pl, among others.

Boundaries

What I don't do

A specialist is defined as much by what they don't do. This is where my part ends.

Backlog by the hour

I step in where you need PrestaShop knowledge, not extra capacity.

Replacing your team

I don't replace your developers. I work alongside them, under your brand if you prefer, and the project and the client stay with you.

Server administration

I'm not a server administrator. I help with the basics and translate between the store owner and the server admin, so both sides are talking about the same thing.

Evidence, not claims

Four cases about where a change belongs in PrestaShop

These aren't projects for software houses: they come from end clients and from my own module. They show how I work inside someone else's code, and you can check the first one yourself on GitHub. Further cases, from production outages to stock levels out of sync, are in the case studies.

sklep4x4.expedycja.pl publicly verifiable

A fix accepted into the PrestaShop core

Problem

Stock levels for product packs didn't add up. I disabled the customizations and diffed the files against a clean core: the bug was in the PrestaShop engine itself. Pack::getQuantity ignored the "Decrement pack only" type, because empty(0) evaluates to true.

What I did

I reported the bug together with a fix. A project maintainer merged it into the 9.2.x branch. In the client's store, I moved the workaround from a core modification to an override.

PR #42123

fix merged into the 9.2.x branch

#42079

issue closed as completed

a group of several stores 2016-2017

A coding standard for a team that didn't have one

Situation

A client with no in-house IT department, several stores on one multistore installation, and a few external developers. One of them had deployed a module to production that changed stock levels with raw SQL queries, bypassing PrestaShop's classes.

What I did

I wrote a dozen or so rules: separate tables instead of core changes, native functions for talking to the database, testing in each developer's own environment, and a review by me before anything reached production. I enforced them through code review and coordinated around 10 people: developers, a designer, the hosting provider and the warehouse team. Separately, in 2017, I deployed two stock-consistency checks scheduled to run via cron.

~10

people coordinated around the client's stores

80+

products whose combination quantities didn't add up to the total, fixed when the checks were deployed

karcher-apeks.pl January 2026

Sorting before pagination, and an exception to my own rule

Problem

The product listing had to be sorted by availability for sale. For the order to stay correct across every page of the listing, the sorting has to happen before pagination, inside the core.

What I did

I analyzed the core's listing logic: providers, hooks, pagination, stock status and backorders. I tested the concept and implemented sorting by available_for_order. Given the client's limited budget, I left part of the change in the Category class instead of an override. It's a deliberate exception, not my standard: before the next update, that change has to move to an override.

production

the change runs in the client's live store

core + module

change in the Category class and in the filtering module

my own module EU Directive 2023/2673

One module across three generations of PrestaShop

Situation

Since 19 June 2026, every store selling to consumers in the EU has to offer a digital withdrawal function, regardless of which PrestaShop version it runs on.

What I did

I built samilreturns for PrestaShop 1.6, 1.7 and 8, following the directive's requirements: a withdrawal form customers can use without an account, multilingual and multistore-compatible. One compatibility layer handles the differences between 1.6 and the newer versions, instead of conditions scattered through the code. The code runs on PHP 5.6 and 8.x alike, and I test it on three PrestaShop versions in Docker. I wrote it with AI assistance, using tooling I set up specifically for this project. It runs in production in several stores.

1.6 → 8

PrestaShop versions supported by one module

production

running in several stores

How it works

Working together, step by step

Work modes and how I price a job are covered separately, in How I work.

A short call

You describe the project and where it stands. We check whether there's a fit, no obligation and no cost.

Getting up to speed is paid, and priced upfront

Before I can advise on anything, I need to get to know your code, configuration and data. That time is paid, you know the amount before I start, and it ends with a report that's yours to keep.

Scope and a cap on hours

Hourly billing with an approximate cap, no detailed quote. I don't estimate an outage in advance: what matters there is reaction time, not a price.

Reaction time

I react to an outage within 4 hours, Monday to Friday, 9:00-18:00 CET/CEST. For long-term clients it can be faster, sometimes within the hour. Urgent work carries a surcharge, stated plainly before I start.

Next step

Describe the case your team is stuck on

Tell me which PrestaShop version the project is on and what isn't working. We start with a short call, no obligation.

Describe the case