Rebuilding a legacy system application for Huzzay’s ecommerce platform

Our first outcome was to build these journeys well enough to identify the states, dependencies and rules that the new application would need to carry forward. The existing PHP application remained an important reference for the consumer experience. We put together the right taxonomy of operations, workflows and actions based on the roles living on the platform. Merchants and administrators became part of the same product picture. Recommendations needed a catalogue, the catalogue needed operators, merchants needed a way to manage products, and Huzzay needed a way to manage merchants, taxonomy and platform activity.

By mapping these relationships before fixing the architecture, we developed a richer technical brief. The product was becoming a connected system of users, roles, data and operational responsibilities, and each new layer gave the technology evaluation more context.

An integrated design and engineering team gave us a useful way to work through this ambiguity. Our design team organised a focused workshop around the product flows, helping engineering turn requirements into journeys, sketches and lightweight interface structures that could be discussed and tested quickly.

We used Figma Make to visualise parts of the application at greater fidelity where a screen or interaction could clarify the system. The purpose was to make the behaviour concrete enough for engineers to interrogate before those assumptions were embedded in the build.

A merchant product flow, for example, immediately raised questions about where product data lived, which taxonomy it belonged to, who could modify it, what made it publishable and when it became visible to a host.

The design effort was intentionally concentrated around the areas where ambiguity was highest. We came to think of this process as technical visualisation: using flows, sketches and lightweight interface prototypes to make system behaviour visible before the architecture hardens around it.

With that product picture becoming more complete, we could evaluate architecture against a system we understood much more deeply.

We evaluated approaches against the journeys, data relationships and operational responsibilities that were becoming visible, allowing each option to be tested against a more complete view of the application.

Webflow with a custom Node and PostgreSQL backend was one early direction. We also considered Shopify and WordPress against the shape of the product, looking at how comfortably each approach could support Huzzay’s creator, guest, premium and catalogue behaviours.

We then explored whether AI-assisted development could accelerate the implementation. Lovable was evaluated as a way to generate a React frontend quickly, giving us another hypothesis to test against the increasingly clear product model.

Each exploration sharpened the technical brief. Authentication, subscription entitlements, shared gift states, recommendations, merchant data, payment events, notifications and relationships across multiple user types all needed to work coherently within the same product.

The Lovable feasibility pass focused on a practical question: how much of Huzzay could be accelerated through an AI-assisted frontend approach, and where would custom engineering still carry the majority of the product responsibility?

The assessment showed that Lovable could accelerate screen generation, while the substantial engineering effort sat in backend behaviour: authentication assumptions, reservation integrity, subscription entitlements, payment webhooks, notifications and multi-table consistency. A generated frontend paired with a separate custom backend would also introduce two codebases, two deployment paths and an additional integration layer.

The feasibility study gave us enough evidence to stop that route before implementation. It clarified where the complexity actually lived and helped us avoid spending build effort on an approach that would shift rather than reduce that complexity.

The technology decision became the outcome of the product and system model we had developed through discovery and the final decision was grounded in the product model we had spent time making visible. It reflected the behaviours, roles and operational relationships that had emerged through the earlier exploration.

Huzzay was rebuilt as a Next.js application with Supabase providing authentication and Postgres, while Razorpay supported premium subscriptions. Supabase also gave us a common foundation for roles, row-level security, storage and deliberate data operations around behaviours such as reserving or cancelling gifts.

Next.js was the decision that survived contact with the product. That line became a useful shorthand for the way the architecture was selected through iterative exploration and increasingly precise requirements. The process gave us confidence that the chosen stack was responding to the actual shape of the application. Product discovery and technology evaluation had become part of the same decision-making loop.

The recommendation layer brought an operational ecosystem into the application.

Consumer, Merchant and Admin were developed as connected surfaces supported by the same backend. Authentication and roles determined which part of the application a user could access, while the shared data model connected products, recommendations, wishlists, occasions and platform activity across the system.

The consumer application retained a Tailwind implementation closer to Huzzay’s brand language. The Admin and Merchant portals used MUI with a token layer suited to operational tools. Supabase connected authentication, roles, row-level security and data across all three surfaces.

This gave each role an interface suited to its work while maintaining a common product architecture underneath. The three experiences could evolve around their respective jobs while continuing to operate from the same source of truth.

The exploration also helped us define the boundaries of the first release. Ideas such as group gifting, deeper theme capabilities and additional messaging features were considered in enough detail to understand how they could eventually fit into the product, without expanding the immediate build unnecessarily.

This became an important part of the reconstruction process: understanding enough of the future product to make sound architectural decisions, while keeping the current build focused. Visualising future capabilities allowed the team to understand their implications without forcing them into the first release, keeping the architecture aware of the product direction while the build remained focused.

Visualisation methods are a practical way to clarify technical requirements at the points where documentation alone left behaviour open to interpretation. A journey, sketch or interface can make a system relationship easier to examine because it places states, actions and users in context. On Huzzay, that context helped engineering understand what happened before and after an interaction, which data moved with it and which other roles depended on the outcome.

It also helped reveal the true size of certain requirements: The value of the artefacts came from the decisions they accelerated. They created a common language for design, engineering and product discussions while keeping the work focused on the build.

The Huzzay engagement ultimately became an exercise in iterative technical discovery. The brief became more precise as the team understood more of the product, and the architecture evolved in response to that understanding. This approach also gave us a disciplined way to handle future ideas. By visualising concepts such as group gifting and deeper theme capabilities, we could understand their likely place in the system and make informed decisions about what belonged in the current release.

The project delivered a modernised application and a working method we can carry into other legacy re-engineering engagements.

Know more about our engineering solutions here or contact us