B2B and B2C storefronts
Built around how the buyer actually decides, not around a theme that came with the platform.
We build storefronts for catalogues with variants, bundles and a buyer who compares before committing. Industrial manufacturing, automotive tools, furniture and fashion so far.
Impulse retail is solved. What is not solved is a catalogue with variants and bundles, a buyer who visits four times before deciding, and a corporate site sitting on a different stack from the store.
Variants, bundles and configurable products are where a generic setup runs out and the workarounds start.
Friction in the last three steps costs more than anything you change on the homepage.
Built around how the buyer actually decides, not around a theme that came with the platform.
Variants, bundles and configurators modelled properly, so the workarounds never start.
Fewer steps, clearer pricing, and automated follow-up on the carts that stall.
Corporate site and store on one path, so the buyer does not fall into a gap between them.
Stock, pricing and orders moving between the store and the systems that run the business.
Tracking that answers where the drop happens.
Two of these are deadlines that have already passed, and most storefronts have not caught up.

This one is an overview that covers several clients. Across industrial manufacturing, automotive tools, furniture and fashion, the recurring problems were the same: fragmented journeys between the corporate site and the store, catalogues the platform could not model, and checkout friction nobody had measured.
Where pricing is per customer, the catalogue is large, and the order is a conversation.
Furniture, tools and anything a buyer researches before committing.
A corporate site on one platform and a store on another, with no funnel across the two.
Growth into new markets, where tax, currency and stock stop being a detail.
Related reading: the ecommerce case study, web application development and custom software development.
Use the platform, unless your catalogue or your pricing does not fit it. The usual reasons to build are per-customer pricing, configurable products, and an ERP that has to be the source of truth. We will say which applies on the first call.
Usually yes. Stock, pricing and orders moving correctly between the store and the back office is normally the part that decides whether the project was worth doing.
Six to twelve weeks on a typical engagement. Catalogue complexity and the number of integrations move that more than page count does.
You do, from the first commit. Repositories and cloud accounts stay in your name.
Thirty minutes with the engineers on the products you sell, how they are priced and what the store has to talk to.