Rebuilding a fragmented purchase path

The problem

A personalized nutrition startup sold a supplement the customer configured before buying. The journey crossed two applications: choose a product in the e-commerce app, cross into a separate configurator to set the formulation and dosage, come back for basket, payment and confirmation, then a dashboard afterwards for reordering.

It worked. What it wasn't was one product. Different parts had been built at different times by different agencies and freelancers on older stacks, so branding, interaction patterns and UX diverged section by section, and each fragment carried its own analytics.

What made it hard

The formulation is a dosage. It is not a shopping preference. Losing it silently, or restoring the wrong one, is not a UX defect in a product somebody swallows every day.

It was the revenue path. Everything between arriving and ordering was in scope. There is no low-stakes corner of a checkout to practise on.

Nobody could see what was working. Analytics were spread across the fragments, so the two questions the business most wanted answered — where do people drop out, and is that technical or is it the proposition — meant stitching several tools together for every attempt.

My role

I grew into sole owner of the frontend domain: both customer-facing applications, their technical direction, and the standards they were maintained to. Rebuilding the two of them was my responsibility. The call to rebuild rather than patch was the company's, taken for the reasons below; how it was built was mine.

The decision that shaped it

The configuration lives on the server, and every change writes.

Not a draft in local storage. Not state encoded in the URL and handed between the two apps. Not a session that expires. The formulation is persisted to the database as it is built.

That costs a write per interaction, which is exactly the sort of thing you would normally optimise away. It buys the one property that mattered: the configuration is never only in one place, and it never depends on the browser that created it. Someone who abandons halfway through — closes the tab, runs out of time, comes back on a different device — finds their work where they left it, because it was never client state to lose in the first place.

It also turns the boundary between the two applications into a non-event. Crossing back into the e-commerce app is not a handoff of state, because neither app owned the state to begin with. The hardest-looking part of the architecture stopped being a problem by making it nobody's job.

Rebuilding rather than repairing

The cheaper move is always to modernize the fragments in place. We rebuilt the path as one product instead, and it was worth more than consistency, because it made the business legible: one product with analytics attached to it, instead of the same question answered by stitching several tools together across pieces that disagreed.

That turned A/B testing and funnel analysis from a data-collection exercise into an ordinary part of shipping, and made it possible to tell a technical drop-off from a product one. The new path went out and was then watched closely — where people were leaving the funnel, and whether the cause was the software or the offer.

Reordering has to tell the truth

The dashboard gives a returning customer their saved configuration alongside a snapshot of the product as it was actually made.

The catalogue rarely changed. When it did, we told the customer their original formulation was no longer available, and they had to review it before reordering.

This is the decision I would most want to be asked about. The convenient version — map the old configuration onto the nearest current equivalent, keep the one-click reorder intact — is better for conversion and wrong for a health product. Someone reordering a supplement is reordering a dose, and they are entitled to know it changed.

What I took from it

The engineering decision I am most confident about is the least clever one. Writing the configuration to the server on every change costs more than it needs to, and it removes an entire category of failure: the class of bug where a customer's data exists only in a tab they have already closed.

The second is that domain constraints outrank interaction conventions. Everything I know about checkout says remove steps. A formulation that changed underneath a returning customer is the case where the extra step is the product.

Specifics are limited by confidentiality. The persistence model, the rebuild sequencing, and the trade-offs behind both are open in an interview.