Web, UX & products that convert

A pretty site isn’t a product. It’s the most common trap in digital: the agency delivers a splendid showcase, you pay ads to bring people there, and on the second click — when the user tries to do something — the thing breaks, stalls, or simply does nothing. Because under the varnish there is no engine. This guide collects the articles on how you move from the showcase site to the digital product that converts: a serious frontend, tied to a real backend, that makes whoever arrives do the thing they arrived for — and do it all the way.

The principle: the product is the face, but behind it you need the engine

The thread that ties these articles is the distinction between showcase and product. The showcase shows you and that’s it: the visitor reads, looks, and leaves. The product makes you do something — book, buy, manage, produce a result — and to do that it needs two things the showcase doesn’t have: a usable face (the frontend, with its states, errors, empties, permissions) and a real engine behind it (the backend, the data, the logic). When the face is missing, you have an engine the client doesn’t know how to use (the “desert”). When the engine is missing, you have a face that collapses on the first real click. A product is both, stitched together.

The other thread is that the value, in a product, sits in the invisible 80%: not the ideal case where everything goes well, but the crooked states — what the user sees while it loads, when they make a mistake, when they have no data, when they don’t have permissions. That’s where a product closes or loses people at the last metre.

Showcase or product: understand what you have (and what you need)

• «The agency delivered the site, but the “backend” is a Google Form» — the difference between a showcase and a product, and when something born for another purpose presents the bill: showcase site versus digital product.
• «The site is pretty and on the second click it breaks» — why slowness and errors make clients leave, and how perceived speed is frontend work: the slow site that makes users err.
• «I pay for ads and lose people at the form» — where a flow gets abandoned and how you close it, instead of buying more traffic for a leaking bucket: booking and cart abandonment.

Building product (for whoever sells it to others)

Part of this guide is for whoever builds the product and resells it — software houses and agencies:

• «I have the backend, I’m missing the face» — why a software house without frontend delivers a desert, and how you close the product working as two teams without bounce-backs: frontend for software houses.
• «I rebuild every project from scratch, the margin dies» — white-label to sell the same product to many clients under their brand: one core, many skins: white-label for your agency.

When there’s AI inside

More and more products have a piece of artificial intelligence, and here the boundary is everything:

• «I want to sell an AI product to clients» — from ChatGPT in a demo to a real, solid, resellable product: launching a white-label AI product.
• «They told me I need “a model”» — no: you need a process that produces a reliable output, not a chatbot that promises everything: LLM product versus chatbot.

The piece that decides everything: the states, not the ideal case

Under every product that converts sits the discipline of states. The pretty case — data present, everything works, user with the right permissions — is 20% of the work. The other 80% is what happens when things go crooked: loading, the error that has to say what to do instead of “something went wrong”, the empty state that guides the new user, the permissions that show each person only what they can do. A product made by whoever cuts these corners works in the demo and collapses on the first real day. That’s why serious frontend isn’t “a bit of CSS”: it’s where the experience is born or dies.

And the most expensive errors live in the stitching between face and engine: the backend that refuses because of a rule of its own (slot taken, expired code) and the frontend that doesn’t know how to explain why, so it shows a wall instead of an action. This only gets solved with a single direction that holds both sides together — the same pair of hands I describe throughout the guide to buying custom software.

How to use this guide

Start from the article that describes your pain. Each one includes the count of what you’re leaving on the table, what changes concretely on screen, the honest timeline, and the “it’s for you if / it isn’t for you if” section — because sometimes a showcase really is enough, and saying so is part of the job.

When you want to see what it would look like to close your flow for real — on your product and your real users — the starting point is the project portfolio or two lines in contacts.

Below you’ll find all the articles in this guide.