Krenno
All projectsCase study
Web AppManufacturing2022webiosandroid

Fenstra

Specify a custom door the way a manufacturer would — then buy it like a modern digital product.

A visual commerce platform that turns custom doors and windows into a guided buying experience.

Client

Engagement

manufacturer

Krenno roleProduct strategyExperience designCross-platform Flutter engineeringConfigurator architecture+3 more
Positioning

Why this product exists

Fenstra replaces fragmented showroom, catalog, and quotation workflows with a single visual commerce experience. Customers see the product they are specifying. Merchandising teams control every option, finish, and configuration from one administrative surface. The result is a complete digital sales channel for a complex manufactured product, not a static brochure.

This project proves Krenno can take a complex manufactured product — with coatings, hardware, dimensions, and finish combinations — and turn it into a polished, dual-surface digital commerce system. It shows we can design a consumer configurator and an operations CMS that share one information architecture, ship that experience across web and mobile from a single Flutter codebase, and back it with a cloud data and media platform that merchandising teams can run themselves. For the next client, that is the capability to productize a catalog-heavy business into a guided buying platform with a serious administrative layer behind it.

Built for

  • Homeowners specifying entrance doors and windows
  • Architects and interior designers selecting aluminium systems
  • Dealers and showroom teams guiding customers through options
  • Manufacturing merchandising and product operations teams
  • Brands that need visual configuration for configurable physical products
The story

Challenge, approach, solution

01

The Challenge

Aluminium doors and windows are not SKUs you pick from a shelf. A single entrance door is a combination of model, opening type, width and height, coating system, frame and panel color, hinge type and orientation, glass, handle, and lock — plus overlay positions for hardware on the product image. Manufacturers need a digital channel that can carry that complexity without turning the customer into a specification engineer, and without forcing the merchandising team to file a development ticket every time a finish, banner, or door style changes.

02

Our Approach

We treated configuration as a product, not a form. The customer experience is a branded storefront with catalog merchandising, saved designs, and a multi-step visual wizard that keeps the live preview and price in view at every decision. The operations experience is a dedicated CMS with a navy brand shell, collection-aware catalog management, image upload, and structured door-style records that include performance copy, frame dimensions, tax fields, and hardware overlay coordinates. Both surfaces share one Firebase-backed product model so a finish published in admin is the same finish a customer configures on the storefront.

03

The Solution

Fenstra is a complete visual commerce system: phone authentication into a branded home, featured categories and best-selling doors and windows, a product detail surface with specifications and reviews, and a panel-door configurator that walks the buyer from model selection through dimensions, coatings, hinges, glass, handles, and locks. Behind it, Fenstra Admin gives merchandising control over homepage banners, ten option catalogs, door styles, and assembled door configurations — with imagery stored in Firebase Storage under a dedicated product media tree.

Experience

The Experience

A customer signs in with a phone number, lands on the Fenstra storefront, and moves from hero merchandising into featured categories, best-selling doors and windows, and previously saved designs. Opening a product reveals brand, model, availability, tax, installation preference, specification grids, and reviews. From there the buyer enters the Panel Door Configurator: a frosted configuration panel over a live door preview, a progress timeline, and a persistent unit price. Each step is a focused decision — choose the door model, set dimensions and opening type, select powder coating, anodised, or wooden finish with color swatches, configure hinge type, orientation, and color, then choose glass, handle, and lock. Merchandising teams work a parallel experience: a collapsible brand-navy side navigation that moves between homepage banners, option catalogs, door styles, and door configurations, with image upload and structured forms for every record the storefront needs.

Product

What we built into the product

Guided Visual Configurator

A multi-step door configuration wizard that walks buyers through model, dimensions, opening type, coating system, color, hinges, glass, handles, and locks while a live product preview stays on screen.

Live Product Preview

Door imagery renders against a wall context with hardware overlay coordinates for handles, hinges, and locks, so the specification the customer builds is the product they see.

Branded Commerce Storefront

A Fenstra-branded home experience with navigation, search, account and cart entry points, hero merchandising, featured categories, best-selling doors and windows, and a saved-designs library.

Product Specification Surface

A product detail experience covering brand, model, availability, pricing and tax, installation preference, panel copy, frame dimensions, door details, color, and performance attributes.

Merchandising Admin Console

Fenstra Admin is a dedicated operations surface for homepage banners, category and option catalogs, door styles, and assembled door configurations — the system of record for what the storefront can sell.

Configurable Option Catalogs

Independent catalogs for category, color, hinge, handle, lock, coating, frame, glass, and coating color, so merchandising can expand finishes and hardware without redesigning the product.

Door Style and Configuration Library

Door styles carry commercial metadata — pricing, performance, description, brand, model, tax, availability, frame dimensions, and hardware locations — then assemble into complete door configurations that bind type, colors, coating, and glass.

Also included

Cloud Media Pipeline

Administrators upload product and banner imagery from the browser; files are stored in Firebase Storage under a dedicated Fenstra media structure and referenced from Firestore records the storefront reads.

Phone Authentication Flow

A dedicated sign-in and OTP confirmation sequence that gates the configurator behind a phone-number identity step designed for consumer and dealer access.

Saved Designs Workspace

Customers keep previously specified doors in a My Designs library so configuration work can be revisited, compared, and continued across sessions.

Reviews and Social Proof

Each product includes a reviews surface with an empty state and a structured write-a-review form, giving the catalog a trust layer alongside specifications and price.

Responsive Cross-Platform Delivery

The storefront is built in Flutter with responsive breakpoints for mobile, tablet, and desktop, targeting web, iOS, Android, and macOS from one application architecture.

Gallery

Product surfaces

Visual placeholders mark where final screens and captures will live. Drop assets at the paths shown on each tile.

Engineering

How it's built

The system is a dual-client, shared-data product. The customer application (Fenstra) initializes Firebase, hydrates a ConfiguratorBloc from aluminium base-design records, and presents a storefront-to-wizard flow: authentication, home merchandising, product detail, then a stacked preview-and-panel configurator. The operations application (Fenstra Admin) is a side-navigation shell over four merchandising domains — banners, option catalogs, door styles, and door configurations — each writing Firestore documents and Storage objects. A TypeScript Express service sits beside the clients as the HTTP administrative boundary. A typical merchandising-to-customer path is: an operator uploads an image and saves a door style or option record; Firestore and Storage persist it; the storefront queries base-design and product-detail collections filtered to the aluminium line; the configurator renders preview, price, and option steps from that product model.

modularAPI-drivencloud-nativecross-platformshared-data dual-clientrepository and BLoC on the storefront

Decision

Two Flutter applications on one Firebase product model

Consumer configuration and merchandising administration have different information density and permissions, but they must never drift into two catalogs.

A finish, banner, or door style published once is the record the storefront sells, which is the foundation of a maintainable visual commerce system.

Decision

Collection-per-option-type catalog design

Hinges, glass, coatings, and colors change on different cadences and need independent merchandising.

The CMS can grow the option set without rewriting the configurator, and the storefront can query aluminium designs by the attributes that actually differentiate the product.

Decision

Hardware overlay coordinates on the door-style record

A door image is incomplete until handle, hinge, and lock sit on the correct axes.

Configuration becomes a visual specification instead of a text form, which is what makes the product commercially useful for a manufacturer.

Stack

Fenstra is a dual-client Flutter system on a Firebase-backed product platform, with a TypeScript Express service layer for administrative API work. The stack is chosen so one product model, one media store, and one design language can serve a consumer configurator and an operations CMS across web and mobile. It is the architecture of a visual commerce product, not a single-page brochure.

FlutterDart BLoC and flutter_blocResponsive FrameworkOpen Sans and PoppinsNode.js and ExpressTypeScriptCloud FirestoreFirebase HostingFirebase project environmentsGitHub ActionsFirebase AuthenticationFirebase StorageCloud Firestore client SDKsEquatable and repository layering
Process

From brief to shipped product

  1. 01Discovery

    We mapped how an architectural aluminium door is actually specified — model, opening, dimension, coating system, colors, hardware, glass — and separated the customer decision path from the merchandising taxonomy those decisions depend on. That produced two products that share one model: a guided storefront and an operations CMS.

  2. 02Design

    The storefront is designed as a manufacturer brand experience: Fenstra navy, Open Sans, glassmorphic configuration panels, live preview, and a persistent price. The admin console is designed as a working merchandising tool: Poppins, a collapsible navy shell, collection switching, and structured forms for door styles and configurations.

  3. 03Development

    Engineering proceeded as a dual-client Flutter delivery. The storefront received authentication, catalog surfaces, product detail, and the configurator wizard on BLoC. The admin received banner, option, door-style, and configuration workflows against Firestore and Storage. A TypeScript Express layer was established as the administrative API boundary.

  4. 04Testing

    The product was validated as a full merchandising-to-configuration path: publish options and door records, confirm they resolve on the aluminium catalog queries, and walk the wizard through model, dimension, coating, hinge, and handle steps on the responsive canvas.

  5. 05Launch

    The admin console is hosted as a Flutter web SPA on Firebase Hosting with a GitHub Actions deploy path onto the Fenstra development environment, and the storefront is delivered as the same Flutter application across web and mobile targets.

Challenges

Hard problems, clear outcomes

Turning a manufactured product into a guided decision path

Problem

An architectural aluminium door is a combinatorial product. If every option appears at once, the customer stalls. If options are hidden, the specification is incomplete and the manufacturer cannot fulfill it.

Approach

We designed a five-stage wizard — model, dimension and opening, coating and color, hinges, then glass, handle, and lock — with a live preview, progress timeline, and unit price held constant across steps.

Outcome

Configuration reads as a product experience. The customer makes one class of decision at a time, and the manufacturer still receives a complete specification.

Keeping consumer and operations surfaces on one catalog

Problem

Showroom software fails when merchandising updates live in a spreadsheet and the configurator lives in code. Finishes drift, banners go stale, and engineering becomes the bottleneck for catalog change.

Approach

We built Fenstra Admin as a first-class product: collection-aware catalogs, door-style metadata, assembled configurations, and a Storage-backed media pipeline that the storefront reads as its source of truth.

Outcome

Merchandising can publish the option set the configurator sells. The two applications stay aligned because they share the same Firestore product model.

Making hardware placement part of the product record

Problem

Handle, hinge, and lock positions are not decoration. They have to sit on the door image at the coordinates the configuration implies, or the preview stops being trustworthy.

Approach

Door-style records store x and y locations for handle, hinge, and lock. The configurator model carries those locations through to the preview so hardware is data, not a Photoshop layer.

Outcome

The visual preview can represent a specified door instead of a generic hero image, which is the difference between a catalog and a configurator.

Shipping a visually dense commerce UI across devices

Problem

A door preview, frosted decision panel, price, and progress indicator fight for space. A layout that works on a 1440-pixel merchandising canvas has to remain usable on a phone in a showroom.

Approach

We used Flutter with Responsive Framework breakpoints and a shared Fenstra visual system — navy brand, corner accents, Open Sans — so the same information architecture scales instead of being redesigned per platform.

Outcome

One configurator codebase serves web and mobile targets, which is the only sustainable way to keep a manufacturer brand consistent at the point of specification.

Proof

What this work proves

Fenstra gives a manufactured-product business a complete digital sales channel: customers specify doors and windows visually, merchandising controls the catalog, and both surfaces run on one product architecture. The platform centralizes option taxonomies, door styles, configurations, and media that previously lived across brochures, showroom conversations, and disconnected files. It is a working demonstration that Krenno can productize a complex physical catalog into a guided commerce system with an operations console behind it.

Product design for configurable commerceVisual product configurator engineeringCross-platform Flutter deliveryBLoC and repository architectureFirebase catalog and media platformsAdmin CMS and merchandising operationsManufacturing and architectural-product workflowsDual-surface consumer and operations productsBrand system implementationCloud hosting and CI delivery

What's next

Intelligent specification guidance

Extend the configurator with recommendation logic that suggests coatings, glass, and hardware based on opening type, climate, and the customer's in-progress design so specification stays fast as the catalog grows.

Dynamic commercial pricing

Advance unit pricing into a rules engine that prices dimension, coating system, glass, and hardware combinations so quotes on screen match what manufacturing will fulfill.

Dealer and showroom workspaces

Add role-based dealer accounts, shared design libraries, and quote packets so showroom teams can configure with a customer and send a manufacturer-ready specification.

Have something in mind?

Tell us about your product and we'll help you ship something worth putting on this page.

→Start a project

Next project

Habita — Smart Resident & Property Operations Platform

Unified Living. Seamless Operations. Smarter Communities.

View case study