Clients keep requesting edits on a mockup. How do I get approval on the real thing instead?

This page may contain affiliate links from which Blur Studio earns commissions.

A mockup is a promise about what a page will look like. It can't show how a form actually behaves, how slow or fast something feels, or what the page is like on a client's own phone, which is usually the device they'll actually judge it on. Clients sign off on mockups all the time and then are genuinely surprised by the real thing, not because anyone lied, but because a flat image and a working page are different experiences.

Give the client the real page, not a picture of it

If your site is built from a connected code repository, Netlify generates a Deploy Preview automatically for every proposed change: a genuine, fully working version of the site running at its own private URL, before anything merges into the live site. The client isn't looking at a representation of the page; they're using the actual page, clicking actual links, scrolling on their actual phone.

These previews are already excluded from search engine indexing by default, which matters if the content is confidential or simply not ready for the public yet. For most client-approval situations, that's enough privacy on its own, since the link isn't something a search engine will ever surface.

Adding a password for sensitive work

If you want an extra layer, specifically that the link itself can't be opened by anyone it's forwarded to without a password, Netlify supports turning on password protection at the project level, on the credit-based Pro plan or Enterprise. This is worth using for anything genuinely sensitive, a rebrand before announcement, pricing changes, or work for a client who's particular about confidentiality, where "not indexed by Google" alone doesn't feel like enough. If you're on Free or Personal, you don't get this specific option, and the noindex privacy that already comes with every Deploy Preview is what you're working with instead.

Step by step: how to run this with a client

1. Make the proposed changes in a branch or pull request, not directly on the live site. This is what triggers a Deploy Preview to generate automatically.
2. Turn on password protection if the content needs that extra layer of privacy. Decide this before sharing the link, not after.
3. Send the client the actual preview link, with the password separately if you've set one. Ask them specifically to click through pages and try things, not just look at the homepage.
4. Collect feedback directly on the preview where possible. Netlify's own in-preview comment tool lets a client leave notes and screenshots right on the page, which keeps feedback attached to the exact thing it's about, rather than scattered across emails describing a screenshot from memory.
5. Only merge and publish once the client has actually approved the real version they used, not an earlier mockup from weeks before.

What this actually costs

Deploy Previews themselves don't use Netlify's credit system and are included on every plan at no extra charge. Password protection, if you want it, is a Pro-plan ($20 a month billed monthly) or Enterprise feature, not something Free or Personal includes. The only other cost that applies is the eventual production deploy once the client approves and the change goes live, the same 15-credit cost as any other deploy.

The alternatives, and when they fit better

A Figma prototype is still useful earlier in a project, for agreeing on layout and flow before any real code exists. It's the wrong tool for final sign-off specifically because it can't show real behavior, which is exactly the gap this whole approach is meant to close.

Password-protected staging on a normal host achieves something similar, usually as one shared staging environment rather than a separate preview generated per change, which works fine for a single ongoing project but doesn't scale as cleanly once several changes are in review at once.

A plan detail worth checking before you promise it

Some in-preview collaboration features may depend on your specific Netlify plan and the access level given to whoever's reviewing. Before you promise a client a specific collaboration feature (commenting directly in the drawer, for instance), confirm it's actually available on your plan and that the client has whatever access level it requires, rather than assuming it just works for anyone with the link.

A worked example: a rebrand sign-off that almost went wrong

Say an agency is rebranding a client's site, new colors, new typography, a redesigned navigation menu, and sends over a polished Figma mockup for approval. The client signs off; it looks great. Once the real page goes live, the client calls, unhappy: the navigation menu that looked clean and simple in the static mockup turns out to be genuinely hard to tap on a phone, since the mockup showed one frozen state and never revealed how the menu actually opens, closes, or behaves with a thumb on a small screen. The client's complaint isn't really about the colors or the typography they approved; it's about something a flat image was never capable of showing them.

Had the same approval happened on a password-protected Deploy Preview instead, the client would have opened the actual menu, on their own phone, before signing off, and either caught the problem then or genuinely approved it with full knowledge of how it behaves. The agency isn't at fault for the mockup looking right; the format itself was incapable of surfacing the one thing that mattered most once the page went live. This is the core argument for previews over mockups: it's not that mockups lie, it's that they can't show the thing clients actually judge a finished site on.

Common mistakes with preview-based approval

• Sending the preview link without asking the client to actually use it. A client who just glances at the homepage and replies "looks good" hasn't really tested anything differently than they would with a mockup. Explicitly ask them to click through specific pages, try the form, check it on their phone.
• Forgetting to tell the client the password separately from the link. Sending both together in the same message defeats the point of the extra privacy layer, since anyone who sees the message has both pieces.
• Letting feedback happen over email instead of on the preview itself. Comments made directly on the page, through Netlify's in-preview tool, stay attached to the exact element they're about. The same feedback given over email, days later, often loses the specific context of what exactly looked wrong.

How I'd approach this

I run every client project this way as a default, not an upgrade: real, working previews for sign-off, never a static mockup standing in for the final approval step. It genuinely cuts down on the "this isn't what I approved" conversation, because what they approved and what goes live are the same actual page. If your current process still runs on mockup sign-off and you're tired of the surprises that causes, this is a quick, low-cost thing to fix. Get in touch if you want it set up properly.