Who this is for
Store owners and small teams whose Magento 2 store is live and earning, and who need engineering rather than another extension: a request path that has grown slow, an import that breaks the catalogue, a checkout that fails for some customers, an upgrade nobody dares to run.
I have worked on Magento since version 1, and on Magento 2 with Hyvä daily from 2021 to 2026 at Sanexo B.V. I also build and run Velgrina, a Magento 2 store with a React Native app. The servers under those stores are ones I operate myself.
Typical situations
- Category and product pages take seconds to load and every extension vendor says it is not their extension.
- The nightly product import silently drops attributes, duplicates SKUs or takes the site down.
- Orders arrive with a payment but no confirmation, or a confirmation but no payment.
- The Luma frontend is slow and heavy, and the move to Hyvä has been postponed twice because of the extensions it would break.
- A Magento or PHP upgrade is overdue and the last one broke checkout for a day.
- A previous agency left custom modules without documentation, tests or a staging environment.
What I deliver
- Performance work along the whole request path: full-page cache and Varnish, PHP-FPM, database and indexers, third-party calls, measured before and after.
- Hyvä theme work: migrating a Luma store, replacing extensions that have no Hyvä compatibility, keeping the templates lean.
- Product and catalogue imports that validate before writing, isolate bad rows, keep product identity stable and leave a log that explains every run.
- Checkout, payment, shipping and ERP integrations, with webhook receivers that cope with duplicates and late events.
- Upgrades and migrations: Magento version and PHP upgrades on a staging copy with real data, and moves between hosts.
- Custom modules when the marketplace has nothing that fits, written to survive the next upgrade, with the mobile app or headless frontend in mind.
How it goes
Look at the store as a request sees it. Logs, cache hit rates, slow queries, indexer state, queue depth, the observers that fire on every page. The result is a list of causes with evidence, ordered by impact.
Remove the biggest cause first. I build the change on a staging copy of the store with real catalogue data and a rollback path, and test it before it goes anywhere near customers.
Deploy in a quiet window, then write it down. Monitoring on during the release; afterwards a short note on what changed, what to watch and what I would do next.