Building Haya Threads' E-commerce Engine

The Challenge

• The catalogue is not flat — variants (size, colour, and their combinations) have to be modelled properly at the database level. Get this wrong and you spend the store's life fighting stock counts that don't add up.
• The owners had to be able to run it — a store the founders can't operate without a developer isn't finished, it's a dependency. Every routine action (new product, price change, promo code, order status) had to be a form in an admin panel, not a ticket to us.
• Orders need to keep customers informed — the single largest source of e-commerce support messages is "where is my order?", a question the system should answer before it's asked.
• Nobody was looking for the store — a beautiful store with no traffic is a very expensive brochure. Building it was only half the brief.

Our Approach

We built the admin panel and the storefront as equal halves of one system, rather than treating the admin as an afterthought bolted on at the end — which is the usual reason store owners end up emailing their developer to change a price.

Variants were modelled at the data layer first, before any interface existed, because retrofitting proper variant handling into a live store means migrating orders, stock, and history simultaneously. Order status flows were designed as a state machine with email notifications attached to each transition, so the customer hears from the store at every step.

Reviews were built per product with aggregate ratings surfaced on the product page — the social proof that decides fashion purchases, and the structured data that makes product listings eligible for rich results in search. Then, after launch, we took over the store's SEO: category architecture, product content, technical performance, and the search visibility that turns a working store into a selling one.

What We Built

The storefront runs on Next.js for the page speed that mobile shopping demands, with a Node back-end handling catalogue, cart, orders, and payments. Customers browse categories, choose variants, read reviews, apply promo codes, and pay through an integrated gateway.

The admin panel is where the business actually lives. The team creates categories and products with their media, manages variants and stock levels, watches orders arrive and moves them through their statuses — with customers notified automatically at each change — and creates, applies, or removes promotional codes as campaigns come and go.

Technical Decisions (and the Trade-offs)

• A custom build rather than a hosted platform — Shopify and WooCommerce are excellent, and we build on both, but this project went custom for reasons specific to admin control and business logic. The trade-off: a custom store means we own the maintenance a platform would otherwise handle.
• Next.js for the storefront — fashion buying is mobile, impatient, and often on average connections. Server-rendered pages with fast product loads are a conversion decision before they're a technical one, and they're also what makes the store indexable for SEO.
• Notifications tied to state transitions, not manual sends — every order status change fires its own message automatically, removing a daily human task permanently.

Results

• A store the owners run themselves — the admin panel handles catalogue, stock, orders, and promotions without developer involvement.
• Ongoing SEO retainer — the same team that built it is measured on its search performance.
• Numbers we can share on a call.

What We'd Tell Another Store Owner

• Model your variants before you design anything — size and colour look like interface problems, but they're database problems, and the database is the expensive thing to change later.
• Judge an e-commerce build by its admin panel — whether you can run a promotion on a Thursday night without calling anyone is the actual test of whether the build was finished.
• Budget for being found, not just for being built — search visibility isn't a phase-two nice-to-have.