Magento Developer, Austria and remote
Magento Development for Complex Shops and Existing Teams
Changes take longer every time, and nobody wants to touch the next upgrade.
What Grown Magento Shops Need
Magento can do a great deal, and a shop that has grown uses it: custom modules, several sales channels, ERP connections, special pricing, checkout changes, business logic of its own. That depth is the reason the platform was chosen. It needs someone who can hold all of it in view at once.
Bugs surface where nobody expected them, and every change takes longer than the one before it. I take on demanding Magento 2 work directly: backend, business logic, integrations, performance, upgrades and rescuing projects that have stalled.
Takeover and rescue
A project has stalled, the previous developer is gone, or an upgrade is half finished. I work in through the code, the repository and the deployment history, stabilise the shop and make the next steps plannable again. Magento is not a platform you pick up on the side: I have worked with it since 2008.
Backend and business logic
Custom pricing rules, order flows, product logic, checkout changes and bespoke modules have to fit the business, not merely function.
Integrations and data flow
Stock, prices, products, customers and orders have to move reliably between Magento and everything else. I find the point where data goes missing, runs twice or quietly goes stale.
Ongoing development
Your in-house team or agency needs additional Magento experience for a hard problem. I join for that specifically and work inside the existing setup. Where it helps I take on the architecture too: what belongs where, what should become a module of its own and what should not. The context does not disappear once the ticket closes.
Straight to the Developer Who Understands the Shop
You work with me, André Flitsch. I have worked with Magento since 2008 and with Magento 2 since it was released. No sales layer, no rotating developers, no handover that takes weeks.
I have been building software for over 30 years, working in e-commerce since 1999 and on Magento shops since 2008. That does not mean I know every answer by heart. It means I can read complex systems methodically, spot risk early, and get productive without first selling you a new platform.
You get my assessment, my code and my availability. Architectural decisions get explained. Changes go through version control, static analysis and automated tests. What I build should still make sense to whoever works on it next.
Magento Experience from Live Shops
-
Eleven years on a Magento platform that grew: inventory connected, shop data integrated into the CRM, several B2C and B2B sub-shops added by market, country and currency, plus TTFB and platform performance. Magento does not stand alone there, it is one part of a system landscape. The project in detail.
-
Brentford Computers
My first Hyvä migration went live in November 2020, together with the Swiss agency Diglin, for Brentford Computers. That was at a point when almost nobody had shipped Hyvä. Since then Magento backend and Hyvä frontend go together for me, without every Magento task turning into a frontend migration.
Published contributions
- A fix for the Mollie redirect problem in the Hyvä checkout: written up because I hit it in production before there was anything to find about it.
- mollie/magento2 #1072: duplicate payment reminders when the same shopper orders first as a guest and then signed in. Submitted, and set for the 3.1.4 release.
- magento/magento2 #9718: a broken XSD schema that failed the checkout in developer mode. Merged into the Magento core in 2017.
Most of my work is white-label development for agencies and ships under their name. What is listed here is the part I am allowed to name.
Alongside that runs continuous work on systems I cannot name: performance analysis across database, caching and frontend, developing modules and business logic further, and CI/CD pipelines that make deployments controllable again.
Understand First, Then Change
-
Take stock
I read the code, modules, deployments, logs and data flows. After that it is clear what is urgent, what can wait, and where a change would have side effects.
-
Stabilise
Bugs, blocked deployments and risky dependencies come under control first. New features on an unstable base only make the problem more expensive.
-
Implement deliberately
The solution stays as small as sensible and as robust as necessary. No full modernisation when a targeted fix will do.
-
Verify and hand over
Automated tests, traceable changes and documentation that more than its author can follow. You stay in control even if someone else takes over later.
Not Every Magento Problem Is a Frontend Problem
Hyvä is a strong answer to slow Magento frontends, and I enjoy working with it. Plenty of problems sit deeper in the project though: in business logic, modules, data flows, checkout, deployments, or a backend that grew over years.
This page is about the Magento platform as a whole. If your specific problem is Luma, Hyvä, frontend performance or a migration, the details are on the Hyvä development and Luma migration page.
Magento Support for Agencies and In-House Teams
You do not have to outsource a whole project. I work as a senior or lead developer inside existing teams, take on clearly scoped problems, or stabilise a project until your team can carry it again.
For agencies, I work as an additional developer inside your project. How that runs in detail, who owns what and what happens at handover is on the page for agencies. For merchants, I work directly or alongside your existing agency. What matters is not the org chart but that responsibilities, communication and technical decisions are clear.
Common Questions
Can you take over an existing Magento shop?
Yes. I start with the code, infrastructure, modules, deployments and open risks. After that you get a clear order of work rather than a blanket recommendation to rebuild.
How does a takeover work if the previous developer is unreachable?
I work in through the code, repository, server access and deployment history rather than waiting for a handover. What you mainly need is access to source and infrastructure. If both are missing, we first establish what can be reconstructed.
Do you work with Magento Open Source or Adobe Commerce?
I work with Magento Open Source, and that is a deliberate position. For the large majority of shops, the annual Adobe Commerce licence does not justify the actual difference in capability: backend, business logic, integrations, performance and upgrades are the same work on either edition. If you are already on Adobe Commerce, we go through which licensed features your setup genuinely relies on before any implementation.
Do you work with existing agencies or in-house teams?
Yes. I can take on a single hard problem, add capacity, or stabilise a project technically. On the merchant side I also act as the technical counterpart to agencies and suppliers: someone in-house who can judge a quote and the code that comes back, without being the agency. What the arrangement looks like in detail is something we work out in the first conversation.
Do we have to move to Hyvä to work with you?
No. Hyvä makes sense when the frontend is the bottleneck. Backend, integrations, upgrades and business logic can all be addressed independently.
When is a first conversation worth it?
When a Magento project has stalled, an upgrade looks risky, your team needs extra experience, or changes keep getting slower and more expensive. The first conversation establishes whether I can help and what the sensible next step is.
One Person, From the Question to the Code
I work out what is needed, write the requirement, organise whoever else works on it, and then build it myself. Usually that is three companies, and something is lost at every handover between them. Here there is nobody between your question and the running system.
Where Is Your Magento Project Right Now?
Tell me briefly what you are working on, where things stand and what has already been tried. I will be honest about whether I am the right developer for it.