Prototype before the user story: how I use AI to make decisions earlier

Every PO has lived this scene: scope approved, screens approved, stories well written, and at the acceptance stage the client clicks through the site for the first time and says "oh, but I pictured it working differently".

It isn't bad faith. Nobody can truly evaluate a product that only exists on paper. A static screen shows how something looks, not how it works. The gap between the two usually shows up once development has started, which is the most expensive moment to change anything.

What changed in my process

On the news portals I lead at NVGO, I stopped starting with the specification. I start with a working Next.js prototype, built with AI assistance, that the client browses as if it were the final site.

The conversation shifts from "imagine this area will..." to "click here and tell me what you think". And the questions that really matter come up early:

• How many stories fit on the home page before sections start to look empty?
• Where do ad slots go without getting in the way of reading?
• How does all of this look on mobile, where most readers are?
• Does this weather widget help readers or just take up space?

These are product decisions, not code decisions. But they only appear when there is something to click.

The flow, step by step

1. Client alignment. Before any screen, the same questions: portal style, newsroom output, audience, ad model and mobile usage.
2. First version with AI. I use AI to generate and iterate on the front end quickly from what was agreed. It speeds up the mechanical part; layout, hierarchy and content decisions are still mine.
3. Validation by browsing. The client uses the prototype and I write down what changes. Every round is a conversation about something concrete, not an interpretation of a document.
4. Closed scope becomes backlog. Only then do I write stories and acceptance criteria, describing behavior the client has already seen and approved.
5. Handover to the team. Developers get the base, integrate it with the CMS and review the code before it goes to production.

Where AI helps, and where it gets in the way

AI has drastically shortened the time between "I had an idea" and "the client is clicking on it". Today I can build the first complete version of a portal on my own. But there are risks, and they need managing:

• The prototype looks finished. If the client thinks the site is nearly live, deadline expectations get distorted. I make it clear from day one that it is a validation tool.
• Prototype code is not production code. What AI generates must be reviewed by developers. That's why review is a formal step, not a favor.
• The PO can become a bottleneck. If only I can change the prototype, every change goes through me. So the handover happens as soon as scope is closed.
• It's easy to confuse speed with decision. Generating ten versions of a screen is cheap; picking the right one still takes judgment. AI widens the options, it doesn't choose between them.

What I got out of it

• Less rework during development, because changes in understanding happen before production code.
• Earlier technical decisions: CMS limits, integrations and performance show up in the prototype.
• Better client conversations, because we discuss something real instead of an abstraction.
• Clearer stories for the team, with a clickable reference of the expected behavior.

How to start tomorrow

1. Pick a feature where the client usually changes their mind during acceptance.
2. Generate a clickable version of it with AI, even a simple one, before writing the stories.
3. Validate it with the client by clicking, and write down every change in understanding.
4. Only then write the stories and agree with developers on how the prototype code will be reviewed.

If the list of changes from step 3 is long, you just saved that rework in development.