For store owners

Your store is losing money and nobody can tell you why.

You don't want someone on production who leaves it worse than they found it. You don't want to pay for a diagnosis that changes nothing. This is technical ownership (sometimes called maintenance and support) - not a one-off job on a slice of your store, but staying with it for the long run: keeping it running, selling and free of surprises.

Two kinds of stores

Brand or volume - different priorities, different kind of technical ownership

You're building a brand

Customers pick your store for the brand, not the lowest price, and every outage or bug on the site chips away at their trust. The priority is stability and predictable change: new work tested on a staging environment first, updates checked on a copy of the store, new features that don't break what already works.

You run on volume

Several stores on one shared installation, orders coming in from marketplaces, stock and invoices running through ERP systems. The priority is automation: less manual work per order and a lower cost of service at scale. In my logged work, BaseLinker (now rebranded Base.com, an order-management platform that connects a store to marketplaces) shows up in 258 tasks, the Allegro marketplace in 251, ERP systems in 185. BaseLinker and Allegro aren't the only systems I connect stores to - picking up an unfamiliar one takes longer, and I say so upfront.

Scope

What I actually do

Production outages

Diagnosis under time pressure: logs, database, server configuration. I size up the severity and react accordingly - a dead checkout is not the same emergency as a typo in a product description.

Performance and the database

Slow queries, missing indexes, caching. I point to the specific thing slowing the store down, with a number attached, not a general impression.

ERP and marketplace integrations

BaseLinker, Allegro, ERP systems, payment providers and couriers. I fix the data mismatches between the store and the systems around it.

Things outside the code

Choosing a hosting provider, configuring Cloudflare, talking directly to a module vendor or an ERP provider - if nobody else at your company owns this, it stays with me.

A bigger project

Moving to a newer PrestaShop: tested on a copy first

A store on an older version is still making money, and moving to a newer one is a risk to Google rankings and to sales on switchover day. I move stores from PrestaShop 1.6 and 1.7 to 8.2. I first check on a copy whether the core and the database pass the tests on the new version. That decides whether I update the engine or rebuild the store from scratch. I keep the URL structure. I switch over in the lowest-traffic window, then monitor Search Console and fix whatever it flags.

You provide the graphic design and buy any paid module licenses. You also decide which modules are actually needed in the new version.

This is a separate engagement. You don't need it to work with me, and it doesn't commit you to hand me technical ownership afterward. My fix was merged into PrestaShop's 9.2.x branch (described below), but I haven't moved a store onto 9 yet. For a new project, starting directly on 9 is something we can weigh in the call.

See the upgrade step by step

Evidence, not claims

Four situations, four different kinds of work

No names where I'm not allowed to use them. Numbers where the numbers are documented. More are in the case studies.

toys4boys.pl December 2024

The store stopped responding at peak season - the InPost Pay payment module

Situation

Traffic handled by the InPost Pay module (a checkout payment method from InPost, Poland's largest parcel-locker network) overloaded the server during peak season. The store was down for one to two hours.

What I did

I analyzed the logs, traced the source of the traffic, temporarily disabled the module and added Cloudflare rules. The root cause sat on the vendor's side: after a call with InPost, they made changes on their end, and I re-enabled the module with extra safeguards.

1-2 h

downtime at peak season

no code change

logs, Cloudflare rules and a call with the vendor

zmienolej.pl fitment search

Matching oil to a car without recalculating on every query

Problem

Matching a filter or oil to a specific car means intersecting several attributes at once: make, model, engine. With 4,800 products across nearly 25,000 make/model/engine categories, computing that on every request is slow.

Solution

The result isn't computed when the user searches - a module materializes it on a recurring cron job, in batches of 200 records, updating only the difference instead of rebuilding everything from scratch.

~3M

product-category match entries

25,000

make/model/engine match categories

sklep4x4.expedycja.pl PrestaShop core fix

A bug in the PrestaShop core, not in my code

Problem

While fixing stock levels for product packs, I ran into a bug in the PrestaShop engine itself, not in the store's code.

What I did

I reported the bug on GitHub together with a fix. A project maintainer merged it into the 9.2.x branch - you can check that yourself, without having to take my word for it.

Also for this client

For the same store I built a payment module for orders from abroad in 2023 and extended it in 2025: currency, country, customer-group and carrier settings, and order emails translated according to the payment method.

PR #42123

fix merged into the 9.2.x branch

PrestaShop core issues reported on GitHub

client kept anonymous multistore, PrestaShop 1.6

Another contractor changed stock levels with raw SQL - the data drifted apart

What I found

Another contractor had deployed a module to production that changed stock levels with raw SQL queries, bypassing PrestaShop's own classes. Stock levels stopped matching across a group of stores on one shared installation.

What I did

I traced the bug, fixed the data based on what the database recorded, and changed the module that had been deployed. The other contractor's access to production was revoked.

multistore

a group of stores on one shared installation with PrestaShop's Advanced Stock Management

a few thousand

products with incorrect stock to fix

How it works

Stepping into an existing store

Free call

You describe what's happening. We check whether there's a fit at all. Up to 50 minutes, by phone or Google Meet, no obligation.

Credentials, handled safely

I send the login and password through two separate channels and ask you to do the same. Access I'm given stays in a local password manager secured with a key file and a password, never in the cloud.

Paid audit

Code, database and logs analyzed, finished with a report. You know the audit's price before it starts. It usually takes 7-10 days, depending on my current workload. The report is yours to keep regardless of what you decide next.

Fix or development

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. A surcharge for urgency is stated plainly, never hidden in the quote.

Next step

Describe the problem, not the fix

Tell me what's happening in the store and since when. We start with a free call, no obligation.

Describe your problem