When No Plugin Fits: Building Clikksy a Custom Product Configurator

Making the Builder the Business: Clikksy’s Custom Configurator

The client

Clikksy is an online platform selling personalised cards, calendars, wall decorations, prints & photo gifts to the Swiss market. It’s a product category where the buying decision is visual and specific: a customer isn’t just picking “a frame,” they’re picking a design, a size, a material, a finish, a mount, personalised touch and seeing how it all comes together before they’ll spend money on it.

They own the storefront and the customer relationship; the products themselves are manufactured and shipped by a dedicated production partner.

That model puts unusual weight on one piece of software. Clikksy doesn’t hold stock and doesn’t run a factory the platform is the business. And within the platform, the product builder is the part that matters most, because buying a framed print is a visual, specific decision. A customer isn’t picking “a frame.” They’re picking a size, a material, a finish, and a mount, and they want to see it come together before they’ll spend money.

There’s a second constraint that makes this harder than it looks. Every combination a customer can build has to be something the production partner can actually manufacture. The configurator isn’t just a user interface   it’s the contract between the customer and the factory.

Which means the configurator isn’t a feature of the store. It is the store. Everything else: the catalogue, the checkout, the marketing, only matters if a customer can build the exact product, they want and trust what they see on screen.

The solution

We started with the requirement, not the code.

Before writing anything, we went back to the client and re-established what the product builder actually had to do — the configuration options, the dependencies between them, the rules about what can combine with what, and what the customer needs to see at each step. The previous approach had started from a tool and worked backwards toward the requirement. We reversed that.

We built the configurator custom.

Once the requirement was clear, it was obvious why no plugin had worked: the logic was specific to Clikksy’s products, and general-purpose configurators are built for general-purpose products. So we built it ourselves — a product builder designed around their catalogue rather than adapted to it.

Custom meant we could handle the option dependencies properly, keep pricing accurate across every combination, and make the interface match the way customers actually shop for posters and frames — visually, and one decision at a time.

We structured the entire catalogue with them.

A configurator is only as good as the product data behind it. We worked directly with Clikksy to set up every product and its full variation matrix — sizes, frame options, finishes, and the pricing and availability rules attached to each. This is unglamorous work and it’s where a lot of ecommerce builds quietly fail. Getting it right was the difference between a builder that demos well and a store that sells.

We built it to be maintained.

Clean, documented, and structured so the next change — a new frame material, a new size, a seasonal range — is a catalogue update rather than a development project.

The results

• Launched, Clikksy has a live store.
• The core requirement is solved. The product builder works, custom-built to the actual specification rather than approximated by a plugin.
• A maintainable foundation. No inherited workarounds, no unmapped dependencies — a codebase the client can keep building on.
• A fully structured catalogue, with products and variations configured and ready to scale.