From writing features to owning delivery.
I joined Aproda AG in February 2026 as a full-stack software engineer, working on e-commerce solutions that connect Shopify, React, .NET and Microsoft Dynamics 365 Business Central.
It’s the kind of work where a feature rarely stays within one technology. A seemingly simple customer request might involve the React storefront, a .NET service, an ERP integration and Shopify’s APIs.
But the biggest change for me wasn’t technical. It was taking responsibility for decisions beyond the code itself.
From an idea to fifteen storefronts
One of my first major projects was a multi-shop platform that allows partners to operate their own storefronts while sharing a single Shopify backend and Business Central instance.
I proposed the architecture, built a proof of concept to validate the approach and helped prepare the estimate and commercial offer. From there, I took the lead on technical delivery, working directly with the client to clarify requirements, resolve uncertainties and turn feedback into working software.
Today, fifteen partner storefronts are live on the platform.
Each storefront resolves its partner configuration through a subdomain or cookie, determining which products, content and presentation the customer sees.
Learning to validate assumptions early
Not everything went according to plan.
Two months before launch, I discovered a Shopify platform restriction that invalidated our planned payment approach. It was something I should have investigated much earlier.
I had to rethink the solution, explain the situation to the client and work out a viable alternative without derailing the launch.
It was an uncomfortable lesson, but an important one: a technically sound architecture isn’t necessarily a feasible one. Platform limitations, business rules and operational constraints deserve just as much attention as the code.
I now try to challenge those assumptions before committing to an approach, not after building it.
I would also document the tenant-resolution and cache-invalidation rules earlier next time. Both were correct in code, but lived in my head longer than they should have.
Engineering beyond the storefront
The project also came with the kind of integration challenges that don’t tend to appear in mockups.
Business Central API limits required us to keep requests around 60 per minute and cache repeated reads for about five minutes. Pricing had to remain authoritative on the backend, so the server recalculated it rather than trusting the browser. Authentication involved connecting the client’s Microsoft Entra ID through Clerk and linking those identities to Shopify customer accounts, with a webhook creating the Shopify customer on first login.
Behind the scenes, the stack spans React, TanStack Start, TypeScript, .NET/C#, Sanity and Shopify.
Each integration brought its own constraints, and making them work together reliably was as important as building the interface itself.
Making the work repeatable
My responsibilities also extended beyond the platform itself.
I built the release pipeline, prepared React and TypeScript training materials for two newer colleagues and contributed to an internal experiment around AI model routing.
The multi-shop architecture is now being reused as the foundation for future e-commerce projects at Aproda.
And while the technical challenges have been rewarding, what I’ve valued most is being involved in the full process: understanding a client’s problem, evaluating solutions, making decisions, building the software and being accountable for the outcome.
It’s a broader responsibility than the one I started my career with, and exactly the direction I want to keep growing in.