The agency delivered the site. The «backend» is a Google Form. Why you don't have a product (and customers notice)

The pretty site that doesn’t hold state

The agency delivered the site. It’s pretty, it’s fast, the photos are careful, it looks great on the phone. You paid, you’re happy. Then the first real need arrives: a customer wants to see their order, or book, or upload a document, or access an area of their own. And you discover that behind that nice façade there’s nothing. The “backend” — the part that should remember things — is a Google Form that sends you an email, or a contact form, or nothing. The pretty site doesn’t hold state: it doesn’t know who you are, it doesn’t remember what you did, it doesn’t keep anything. It’s a shop window, not a product.

This is the silent disappointment of a lot of SMEs: they paid for what they thought was “their digital presence”, and they got an online brochure. That’s fine, if you needed a brochure. It becomes a problem the moment your business needs to make something happen online — an order, a booking, an access, a case — because the brochure doesn’t make anything happen: it shows, and that’s it. And customers notice, because they’re used to services that remember who they are and where they left off.

This article is for anyone holding a showcase site and starting to suspect they need a digital product. Let’s see the real difference (it isn’t “more pages” or “prettier”: it’s holding state), what’s exactly missing in a showcase, why no-code and Forms take you to 80% and then slam you into a wall, and — the practical part — how you brief whoever has to build it, because “make me a site” is the request that takes you back to square one.

What’s missing: users, permissions, history, payments, files

Let’s inventory what a showcase site doesn’t have and a digital product does. There are five things, and each is a piece of “memory” the showcase doesn’t own.

Users. A product knows who you are. It recognises you when you come back, shows you your stuff, treats you as you and not as an anonymous visitor. The showcase has no users: whoever arrives sees the same page, and when they leave nothing remains. The moment your business needs “the customer’s area”, the showcase is already insufficient.

Permissions. A product knows what each person can see and do: the customer sees their data, the operator theirs, the owner everything. The showcase has no roles, because it doesn’t even have users. As soon as someone needs to see one thing and someone else not, the showcase isn’t enough.

History. A product remembers. Past orders, bookings, documents, actions taken. It’s the memory that lets the customer “pick up where they left off” and you to know what happened. The showcase remembers nothing: every visit starts from zero.

Payments. A product can collect in an integrated way: the order, the subscription, the deposit, tied to who paid what and when. The showcase, at most, has a button that sends you to an external system, without the “site” knowing what happened afterwards.

Files. A product handles documents: uploads, downloads, permissions on who sees which file. The showcase, if you’re lucky, has PDFs to download, the same for everyone. As soon as this customer needs to upload or download their document, the showcase is out of the game.

These five pieces are what turns “a page that shows” into “a tool that does”. And they require, underneath, work that the classic web agency often doesn’t do: a data model, logic, a real backend. It’s the same invisible work that sits under every internal app that touches company data and under a customer portal: the part you don’t see is the part that decides whether you have a product or a postcard.

The customer who comes back and the data isn’t there

There’s a precise moment when the difference between showcase and product stops being theoretical and becomes an embarrassment: when the customer comes back. The first time, the showcase holds — the customer arrives, looks, maybe fills in a form. The second time, when they come back expecting the “site” to remember them, the showcase treats them as a stranger again. They have to fill everything in again, they can’t find what they did, they don’t have a place of their own. And there the customer thinks something simple: “these people aren’t set up”.

Think about what happens in practice. A customer placed an order and wants to see it again: it isn’t on the showcase, they have to email you and wait. A customer wants to make the same booking again: they have to start from scratch. A customer uploaded a document and wants to check it: there’s no place where it lives. Every time, the showcase dumps on you (email, phone calls, manual work) what a product would do on its own. You don’t only lose efficiency: you lose credibility, because the customer compares your experience with the services they use every day, which recognise them and remember them.

This is the hidden cost of the showcase when the business would need a product: it isn’t that “the site is ugly”, it’s that every operation that should happen online happens instead by hand, via email, with you in the middle. And it’s a cost that grows with the number of customers — the more you grow, the more the lack of a product chokes you.

The bill: what the showcase costs you when you need a product

Let’s put some numbers, declared as estimates but redoable on your company, because “you lose operations” stays vague until you translate it into euro. The cost of having a showcase where you’d need a product hides in two items.

The first: the manual work you dump on yourself. Every operation a product would do on its own — giving the customer the status of their order, letting them rebook, letting them download a document — on the showcase becomes an email or a phone call to handle by hand. If there are, say, 20 of these micro-requests a day, at 5 minutes each, that’s almost 2 hours a day of work that shouldn’t exist: on a yearly basis, over 400 hours, that’s around €10,000 of time thrown away acting as a switchboard between customers and information that should be visible on its own.

The second, larger and invisible: the operations that don’t happen. The customer who would have ordered in the evening but couldn’t (the office was closed and the showcase doesn’t take orders), the one who postponed the booking because it was inconvenient and never did it, the one who went to the competitor who had a client area. You don’t see them in the accounts, because they’re revenue that never came in. But it’s almost always the item that weighs more: a handful of lost operations a week, on a yearly basis, is worth much more than the hours of manual work.

Item	Estimate
Avoidable manual micro-requests (status, reorders, documents)	~20/day
Time lost handling them by hand	~2 h/day → ~400 h/year (~€10,000)
Operations that didn’t happen (orders/bookings after hours, lost customers)	invisible, often the largest item

The point is that the showcase isn’t “zero cost” when you’d need a product: it’s a hidden tax you pay in hours and in missed revenue, and it grows with the number of customers. Reasoning on this cost of inertia is the same exercise you need to understand what it costs to decide by gut instead of on the data: the cost is there, it doesn’t appear on an invoice, and that’s exactly why you never face it.

No-code and Forms: the 80% and then the wall

At this point the reasonable reaction is: “ok, the showcase isn’t enough, but I don’t want to spend a fortune — let’s use no-code, put some tools together, an advanced form”. That’s a fair argument to start, and to validate an idea no-code is perfect: fast, cheap, it lets you see if the thing works. But if the product is the heart of your business, no-code takes you to 80% and then slams you into a wall. It’s worth understanding where that wall is, because it’s always the same.

No-code and Forms instead of software handle the simple, linear case well: a form, a list, a standard flow. The wall arrives when you need the things that make the product yours: a particular logic your business has and others don’t, a serious integration with your ERP, fine-grained permissions, performance when the numbers go up, a tailored experience instead of inside the tool’s rails. There no-code either doesn’t do the thing, or does it halfway with fragile joints that break at the first update. And you end up with a Frankenstein that costs more in maintenance than you would have spent doing it properly, still only does 80%, and for the 20% that counts — which is exactly what distinguishes your company — you have to tell customers “yeah, email me that”.

It’s the same 80% wall you hit with every ready-made shortcut, and the rule for deciding is always the same: how much of your product’s value sits in that 20% the ready-made doesn’t do? If the heart of your way of working sits there, no-code is a trap you discover late. If instead you need something standard and linear, no-code is fine and it would be stupid to spend more — that honesty is part of it too.

What you see in a real product: login, list, detail, action

Let’s stop talking in the abstract and see what a real digital product looks like on screen. Because the word “product” is vague, but the structure is almost always the same, and it’s recognisable. A product has four elements a showcase doesn’t have.

Login. There’s a way to get in and be recognised. From there on, the product knows who you are and shows you your stuff. It’s the door that turns an anonymous visitor into a user with their data.

The list. Once inside, you see the list of your things: your orders, your bookings, your documents, your cases. It’s memory made visible — everything that concerns you, in one place, up to date.

The detail. You click on something in the list and you see the detail: that specific order, with its status, its history, its documents. It’s the level where the product gives you the precise information you’re looking for, without you having to ask someone.

The action. And above all: you can do something. Confirm, order again, upload, pay, change status. Action is what distinguishes a product (where things happen) from an archive (where you look at things and that’s it). It’s the button that, pressed, changes the state of the world — and the showcase has nothing of the kind.

Login, list, detail, action: if a “web” project doesn’t have these four elements, you’re almost certainly buying a showcase, not a product. And if your business needs customers to do things online, you need the second. It’s the same skeleton that holds up a sellable AI product or any serious software: the pretty interface is the surface, but underneath there are users, data and actions, or it isn’t a product.

Checklist: do you have a showcase or a product?

A quick way to see which side you’re on. Answer yes or no:

• Does the site know who you are when you come back (login, personal area)? If no → showcase.
• Does it remember what you did (orders, bookings, documents)? If no → showcase.
• Can you take actions that change something (order, book, upload, pay) and stay recorded? If no → showcase.
• Do different people see different things depending on who they are (permissions)? If no → showcase.
• Is it connected to your real data (ERP, warehouse, customer records)? If no → probably a showcase with a form stuck on.

If you answered “no” to most of them, you have a showcase — which is perfect if you needed a brochure, and insufficient if your business needs to make things happen online. The checklist isn’t there to make you feel guilty: it’s there to understand what you bought, so next time you ask for the right thing.

What it costs to rebuild vs patch

The practical question: if I have a showcase and I need a product, do I patch or rebuild? It depends, and it’s worth reasoning with honesty instead of impulse.

Patching (sticking pieces onto the existing showcase: a plugin for the client area, an advanced form, a last-minute integration) makes sense if the need is small and bounded, and if the showcase sits on a base that lets you add. It costs little immediately. The risk is that, after enough patches, you end up with a fragile system that keeps breaking and costs more in maintenance than you imagined — the classic “spend less three times and in the end you’ve spent more”, with months of malfunctions in the middle.

Rebuilding (building the real product, maybe keeping the showcase as the façade) costs more at the start, but it gives you a solid base to grow on, without the debt of the patches. It makes sense when the product is the heart of the business — that is, when the operations you need online aren’t an accessory but are the way you work or bill.

The practical rule: if you’re losing operations (orders not taken, bookings lost, customers who leave because the experience is inconvenient), the cost of not having a product is already higher than the cost of building it, and patching only postpones. If instead you only need a few extra functions on a brochure that’s fine as it is, patch and don’t spend more. On how you evaluate what you’re actually buying when you commission a build — MVP, maintenance, what’s included and what’s fluff — I wrote in the guide to buying custom software.

How to brief whoever has to build it (not «make me a site»)

Here’s the part that saves you more money than anything else: how you ask for the thing. If you go to whoever builds software and say “make me a site”, they’ll give you a site — a showcase — because that’s what you asked for. If you want a product, you have to brief a product, and it isn’t hard: you describe the operations, not the look.

A one-page brief for a digital product, instead of for a showcase, answers these questions:

• Who uses it? The types of user (customer, operator, owner, partner) and what each must be able to do.
• Which operations have to happen? Not “I want a services page”, but “the customer must be able to order, see status, reorder”; “the operator must be able to approve”; “the owner must see the summary”.
• Which data is needed and where does it come from? Records, products, stock, documents — and whether they already live in an ERP to connect.
• What must it remember? The state the product has to keep (orders, history, documents, payments).
• What happens when things go wrong? The payment that doesn’t go through, the wrong document, the exception. A product handles them; a showcase doesn’t.

Note what is NOT in this brief: words about aesthetics. Not because look doesn’t count, but because look is the easy part — the hard part, and the one that makes the difference between showcase and product, is operations, data, states. If you brief the operations, whoever builds understands you want a product and proposes a product. If you brief only the look, you get a showcase. The whole difference is in the question you ask.

And here’s the point about who: a real product is data, backend and interface together, and they have to come from the same head. The classic web agency is excellent on the façade and often doesn’t have the backend-and-data piece; if you ask them for it, they subcontract, and you get two worlds that don’t talk. For a product you need someone who does UI + logic + data end-to-end, or the interface will be pretty and underneath there will be nothing that holds state — exactly the showcase you wanted to escape.

A typical case: from brochure to a product that bills

A typical profile, architectural, no names. A services SME had a nice site recently redone: careful, fast, with service pages and a contact form. The problem is that all the real work happened after the form: the customer wrote, someone in the office answered by email, sent a quote, received documents as attachments, archived them by hand, updated status by voice. The “site” had nothing to do with it any more: it was a showcase in front of an entirely manual process, and the more customers grew, the more the office drowned in emails and phone calls “where are we?”.

What was done. The site wasn’t thrown away: it was kept as the façade, and behind it they built the product that was missing. Login for the customer, with their area; the list of their cases; the detail with status and documents; the actions (upload the document, approve the quote, see status). Data connected to what the company already used, so the office didn’t re-enter anything. Not “a bigger site”: a product with users, state and actions, behind the same showcase.

At regime, the difference wasn’t aesthetic (the façade was already pretty): it was that operations started happening on their own. The customer saw status without calling, uploaded documents in the right place, approved online; the office stopped acting as a switchboard and started working the exceptions. Manual micro-requests almost disappeared, and some operations that used to get lost after hours started coming in. The honest note: it cost more than a site restyle, and it made sense precisely because the business was losing operations and time every day — if only a brochure had been needed, it would have been a waste, and they would have kept the showcase as it was.

It’s for you if / it isn’t for you if

It’s for you if: you have a site that’s a pretty showcase but your business needs to make things happen online (orders, bookings, client areas, cases, payments); you’re losing operations or dumping on email and phone what a product would do on its own; customers come back expecting to be recognised, and the showcase treats them as strangers; you already have data (in an ERP, in Excel) that a product should use.

It isn’t for you if: you really only need a brochure — present the company, be found, tell the services — and no operation has to happen online (then a well-made showcase is perfect, and a product would be a waste); you’re still validating an idea and no-code is enough to see if it works (start there, the real product comes later); you don’t have real operations to manage, only the need to be present.

Frequently asked questions

How do I know if I have a showcase or a product? With the checklist: does the site know who you are when you come back? does it remember what you did? can you take actions that stay recorded? do different people see different things? is it connected to your real data? If you answer “no” to most, you have a showcase. That isn’t a bad thing in itself — it’s a problem only if your business needs to make things happen online.

Did the agency rip me off? Not necessarily: you probably asked for (or they sold you) a site, and they gave you a site. The problem starts when you needed a product and it wasn’t distinguished from the showcase. Many web agencies are excellent on the façade and don’t have the backend piece: it isn’t dishonesty, it’s that they do a different job. Next time brief the operations, not the look.

Can’t I add a client area with a plugin? Sometimes yes, for small, standard needs. But if the heart is holding serious state (orders, permissions, ERP integration), plugins take you to 80% and then break at the first unforeseen case. The criterion is how much of the value sits in the 20% the plugin doesn’t do. If the heart sits there, patching is postponing.

What does a real product cost compared to a showcase? More, because underneath there’s work the showcase doesn’t have: data model, backend, logic, permissions. But the right comparison isn’t “showcase vs product” in the abstract: it’s what it costs you not to have the product (lost operations, manual work, unhappy customers). If you’re losing operations, the product pays for itself; if a brochure was enough, the product is a waste.

Can I start from the showcase and transform it later? It depends how it’s built. Sometimes the showcase is kept as the façade and the product is built behind it; sometimes the base doesn’t hold and it’s better to rebuild. The important thing is not to kid yourself that “adding pieces” to a showcase gradually turns it into a product: past a certain point, the patches cost more than doing it properly.

Isn’t no-code cheaper? To validate an idea, yes, and it’s the right choice at the start. For a product that is the heart of the business and has to hold growth, integrations and special cases, no-code stops at 80% and the remaining 20% — exactly what distinguishes you — becomes impossible or fragile. Ready-made to validate, custom when the value sits in the part the ready-made doesn’t do.

How do I brief whoever has to build it? Describe the operations, not the look: who uses it and what they must be able to do, which data is needed and where it comes from, what it must remember, what happens when things go wrong. A one-page brief on these points makes it clear you want a product. “Make me a pretty site” makes it clear you want a showcase — and they’ll give you one.

Do I need one person or a team? You need data, backend and interface to be born from the same head (or the same tight team), not from disconnected suppliers who subcontract each other. A product where the interface doesn’t know what the backend does is the showcase with a form stuck on: pretty in front, empty behind.

In one line

A showcase site shows; a digital product makes things happen and remembers them. The difference isn’t aesthetics or the number of pages: it’s holding state — users, permissions, history, payments, files — that the showcase doesn’t have. If your business needs customers to order, book, access, upload, and your “digital presence” is a brochure with a Google Form behind it, you’re losing operations and credibility. No-code is fine to validate; for the real product, that holds your distinctive 20%, you need someone who does UI, logic and data together. And above all: brief the operations, not the look — or you’ll keep receiving showcases.

If you have a showcase and you suspect you need a product, look at the projects I’ve built or drop me a line: we start from the operations that have to happen online and from the data you already have, not from a graphic theme.