BACK
02 / END-TO-END OWNERSHIP

A platform, owned end to end.

At Aproda, where I work as a full-stack software engineer in the e-commerce team, I helped take a client project from its initial requirements to a live platform.

The client, a merchandise provider, wanted to offer individual online shops to its business partners. Each partner needed its own storefront, with different requirements: some shops are private, others serve international customers; some use customer-specific B2B prices, others need different shipping rules. All of them connect to the same Microsoft Dynamics 365 Business Central ERP.

The challenge was to build a platform flexible enough to accommodate those differences without developing and maintaining a separate system for every partner.

From requirements to architecture.

My involvement started before we wrote any code. I proposed a shared, headless architecture, helped prepare the estimate and commercial offer, and took responsibility for the technical implementation and delivery.

The solution combines Shopify for commerce, Sanity for content management, Clerk for authentication and a shared React and TypeScript application built with TanStack Start. Partner-specific configurations allow us to serve different storefronts from the same underlying platform.

Going headless came with trade-offs. We took responsibility for functionality a conventional Shopify storefront would normally handle, including caching. In return, we gained control over the customer experience, the flexibility to accommodate the client's requirements and a foundation we could reuse for future projects.

  1. 01

    Partner request

    Subdomain or cookie

  2. 02

    Partner config

    Assortment, prices, shipping

  3. 03

    Shared storefront

    React and TanStack Start

  4. 04

    Commerce backend

    Shopify and Business Central

One shared storefront resolves each partner from the request, then applies that partner’s rules over the same commerce backend.

Keeping the client involved.

I was also responsible for much of the day-to-day delivery process.

We worked in two-week cycles, with the client involved throughout. For each feature, we'd discuss the requirements, I'd bring examples or an initial implementation, and we'd refine it based on their feedback. I prepared test cases for the client and coordinated releases around the resulting feedback.

A project with this many configurations inevitably comes with unanswered questions. Rather than making assumptions and discovering problems later, I kept track of open decisions and brought them to the client early.

The goal was to keep development moving on what we knew, while resolving uncertainties before they became expensive to change.

  1. 01

    Requirements

    Agreed per feature

  2. 02

    Working example

    Prototype or first build

  3. 03

    Client feedback

    Test cases and refinement

  4. 04

    Release

    Shipped inside the cycle

the next two-week cycle

Every feature ran the same loop: agree what to build, show something working, let the client test it, then release.

A decision I had to reverse.

Not every decision I made was the right one.

The client preferred Payrexx as a payment provider. At the time, I believed Shopify's checkout limitations required a separate payment flow, so I built a Payrexx integration, including webhook handling.

Two months before launch, I discovered a constraint I should have validated earlier: the external checkout approach conflicted with Shopify's platform rules.

I reached out to Shopify's legal team for clarification, but we couldn't rely on receiving an answer before the release deadline. Waiting would have put the launch at risk.

So I changed course. We returned to Shopify's checkout, and I explained the situation and the decision to the client myself. Most of the integration was no longer needed for this project, although roughly two days of work remained reusable for another client.

The experience changed how I approach integrations. Technical feasibility is only one part of the evaluation; platform restrictions and operational constraints need to be validated just as early.

What we delivered.

Today, 15 partner storefronts are live on the shared platform, and the project has stayed within budget. The client has been part of the delivery process throughout, rather than seeing the result for the first time at launch.

The platform also gives Aproda a reusable foundation for future e-commerce projects. The work doesn't have to start from zero with the next client.

What I value most about this project is the breadth of responsibility I was able to take on. From proposing the solution and helping estimate it to building, releasing and correcting it, I was involved in more than just the implementation.

And I learned that ownership isn't only about making decisions. It's also about recognizing when one needs to change, communicating that clearly and following through.

NEXT DECISION

When a working feature isn't working.