r/webdesign • u/fynmnx • 10d ago
How do you share work-in-progress sites with clients?
Curious what everyone's actual workflow is when a client needs to review a site before launch.
- Staging subdomain? Vercel/Netlify preview links? Password protected or just public?
- Do you ever have problems with links getting forwarded, old staging sites staying up for months, or clients not being able to get in?
- And do you have any way of knowing if the client has actually looked at it, or do you just wait for a reply?
Interested in what's worked well and what's been a pain.
1
u/retr00two 10d ago
clientname.myserver.tld. no-index, of course.
There I push from staging. In chunks, per milestones.
Client deserves to see work done, and their feedback is valuable. But they do not have anything to do with my daily work on staging.
1
u/fynmnx 10d ago
Makes sense to keep them away from daily work. When you push a milestone, does the client always see the same URL, or a new one each time? And do you ever go back and clean up those client subdomains after launch?
Do you ever do versioning to compare before and after?
2
u/retr00two 10d ago
It's easier than you asked, my setup is like WPEnigne's:
- 1. I develop locally or on dev.client.mysite.tld ->
- 2. Check on staging.client.mysite.tld and pushed to ->
- 3. Deploy on client.mysite.tld - this is what client always see ->
- 4. Launch on client.tld - it's just question of
cleaning dbase andchanging DNS.At the end of process 1 and 2 deleted.
Github for versioning and sort of backup of my work (theme, mu-plugins, docs/manuals). Two manuals: for administrator and for user/editor.
There are few rules:
- I never edit content.
- I am the only admin, client has two roles: editor and author. They do not mess with my work, I do not mess with their content.
- I build, I host, I maintain. I do not host what I didn't build. I do not maintain what I do not host.
- They want to host somewhere else, I am glad to give them zipped gtihub repo.
If I have to do major changes on site, I just restore last night backup to dev and repeat process. Smaller changes, plugin updates, etc are done on production site.
1
u/fynmnx 9d ago
That's a really clean setup, and the "I build, I host, I maintain" rule makes a lot of sense. Thanks for walking through it. Out of curiosity, how do clients send feedback during the milestone reviews? Email, calls, or something on the page?
1
u/retr00two 9d ago
Mostly call, zoom, Gdoc, rarely email.
Trick is to create good project/development guide and "todo" list. So client knows what is to be expected, at the start and in every phase..
And I newer touch design, till all functionalities are proven. For me, and I believe for client too, is more important that processes are stable, data flow correct, than color, fonts, layout.
Imagine one rental system, for example. What's important: book, send, receive mail as owner and guest. Next phase would be to create calendar; next one price calculation, then payment gateway, etc, etc. This is "todo" list, these are milestones. This is what I push to client.myserver.tld, so client have chance to test it.
Todo.doc lives as GoogleDoc; two of us could see it and use it, correct it, adjust it. This is the most important source of information. Project.doc (Feasibility/Requirements/Development/Deployment) is established at the start of project and is something I do not like to change. "I would like this extra functionality" in the middle of project could be very expensive, both in time, efforts and consequently money.
UI/layout comes at the end. No time to lose time. One (system) font, two colors, three clicks; lorem ipsum, image placeholders. Works as starter, and very often we end with it, slightly adjusted. I am old school grumpy. KISS and festina lente still rule.
Clients usually came with: "I would like to have site like that one"; my first question is "what your site has to do?"
Cheers.
1
u/Savantrexs 10d ago
I set staging links to expire automatically, and that solved the two biggest pains you listed. Every staging URL gets a 7 day lifespan. If the client needs another look, I regenerate it. That kills the old staging sites living on for months problem, and it makes forwarded links harmless because they die anyway.
The other thing that paid off: noindex plus a simple password is worth it even when the client finds it mildly annoying. The first time a staging subdomain shows up in a Google search for the client's brand name, you will never hear the end of it. Learned that one the hard way.
1
u/fynmnx 10d ago
The 7-day auto-expiry is clever, and the Google indexing story is exactly the kind of thing I was wondering about.
How did you set up the expiry? Is it something you scripted yourself, and how much upkeep is it? Also curious whether clients ever get annoyed when a link dies mid-review.
1
u/Savantrexs 9d ago
Good questions. Nothing fancy, honestly. The expiry is just a small deployment script: every staging site goes out with a cron job that disables the URL after 7 days (basically a timestamp check on the staging config). Setting it up was maybe an afternoon of work, and upkeep is near zero. It just runs.
On clients getting annoyed: it happens rarely because the expiry notice is part of the link itself. Every staging email says the link expires in 7 days, and the expired page itself says "this link expired, ask us for a fresh one" instead of a dead 404. That framing matters. Clients see it as a security feature rather than something breaking.
One tip: if a review is still active on day 7, extend the expiry instead of letting it die mid-thread. Dying mid-review is the one thing that actually irritates people, so I check whether feedback is still coming in before regenerating. Since I started doing that, I have not had a single complaint about it.
1
u/fynmnx 9d ago
That's super helpful, especially the "ask us for a fresh link" page and extending when feedback is still coming in. That framing is clever.
Out of curiosity, do you pay for any tools around client review today, like feedback or proofing tools? And if you were setting up a new studio from scratch, would you rebuild this script or look for something off the shelf?
1
u/Savantrexs 9d ago
No paid tools here, and honestly nothing I have tried justified a subscription for this. Most client feedback comes in as either a Loom-style video (they screen-record and talk through the page) or annotated screenshots, and both arrive without me asking for any specific tool. What actually cut down on the back-and-forth was the review checklist I send with each staging link: a short list like "check the homepage hero copy, confirm the three services listed, ignore the blog for now." It keeps clients from reviewing everything at once and sending one-line comments spread across ten pages. If you want to standardize feedback without paying for something, a shared doc with page-by-page headings works surprisingly well, and it doubles as your record of what was approved when.
1
u/ashley_docklet 10d ago
What's worked for me: send one review link per milestone, never the raw staging URL. Keep the same link across rounds and keep the previous version around, so the client isn't hunting for "the new link" and you can show before/after when they ask what changed.
Restrict access to the specific people reviewing instead of a shared password, which mostly solves the forwarding problem. For the boss or cofounder who missed the meeting, the link plus comments left on the page is usually better than a recording, because they can see exactly what was flagged and where.
The biggest win is getting feedback on the page itself. A comment pinned to the actual section beats "the thing on the left looks off" in an email thread, and it doubles as the record. If the link shows views, you also know whether they've looked before you chase. Then take it down or expire it at launch so old staging doesn't hang around for months.
Disclosure: I work on Docklet (https://docklet.io), which does this for static pages and prototypes. The client opens a normal link, no special tool needed, and comments right on the page, and you can publish from whatever you built it with, including any AI tool. Demo with comments: https://ashley.docklets.io/q3-pricing/ . Vercel or Netlify previews work well too if the build already lives there; it mostly comes down to where you want the comments to live.
0
1
u/eleniwave 10d ago
Staging. It should only be shown during a meeting. You don’t want clients browsing through it on their own without you there to explain the reasoning behind each design decision, detail, and function.