Catalog architecture and custom admin for a door store

About the client

Dversen is a door e-commerce with a complex catalog (colors, glass, kits). They needed their own stack: smart card, admin, and SEO contour for the assortment.

The challenge we started with

• Not a catalog website, but InSales logic: variants, prices, stock, exports, orders
• A smart product card: color, glass, size, options, without losing the familiar UX
• An admin as convenient as the platform the client was used to
• A huge catalog: migrating data and variants turned out to be the critical risk

Why they were leaving InSales

The client needed its own infrastructure: less dependence on SaaS, more customization. We set out to rewrite InSales logic in code and keep the feel of a familiar platform, so the team would not have to learn the store from scratch.

Storefront and smart card

The storefront shows a door card with price and configuration: color (eco-veneer and others), glass, door leaf size, and fill options. The buyer builds the configuration the way they were used to on the old platform, but now on their own stack.

Admin for a large catalog

The admin covers products, categories (interior, entrance, trim, hardware...), import/export, prices and stock, exports, reviews, orders, SEO templates, and promo codes. The catalog grid and a "by color and glass" mode show dozens of variants of a single Turin 501 model on one screen. This is the scale that later hit the migration.

Why it was not launched

The catalog turned out to be huge. Moving meant transferring and re-verifying a large number of SKUs, color/glass/size links, stock levels, and established processes. The client assessed the scale of change and decided not to move to the new site, staying on InSales.

The mistake we recorded

We decided to rewrite a huge e-commerce platform from scratch and did not fix the functional scope of the new project firmly enough. Without a clear MVP slice of what is mandatory in v1 and what comes later, the scope grew to almost all of InSales, which is expensive and risky for migration. Lesson: when leaving a platform, first cut the scope and plan the data migration, rather than reproducing everything one-to-one.

How it works

Technology

Before

InSales

Goal

Own infrastructure · platform logic in code

Outcome

Not launched · client did not migrate

Timeline: Catalog architecture · custom admin · configurator

Result and business effect

Shipped a storefront with a smart card and a custom admin: catalog, color/glass variants, orders, SEO, promo codes. Architecture is ready for a large assortment and further growth without a boxed CMS lock-in.

A fit if you need

• You need a product configurator with options, not a flat catalog - Websites
• A migration of a large product range is ahead - Websites
• E-commerce for doors, furniture, or complex SKUs - Websites