When a developer shares a staging link, most clients do the same thing: click around, check that it looks like the designs, and say "looks good" or list visual tweaks. That's a start — but it misses most of the things that will cause problems after launch.
Here's how to review developer work systematically as a non-developer, covering what actually matters.
Check it on your phone first
Before you evaluate anything else, open the staging link on your actual phone. Not desktop. Not Chrome's mobile emulation. Your phone.
Walk through the main customer journey as if you were buying for the first time: find a product, check the product page, add to cart, go to checkout. Note anything that feels clunky, unclear, or broken.
Mobile gets reviewed last on most projects, which means it's where the most problems hide. Reviewing it first means those problems get fixed, not discovered by customers after launch.
Compare against the agreed brief and designs
If the project started with Figma designs or a written scope, pull them up alongside the staging site. Go section by section and check:
- Is the layout matching the design? Key elements in roughly the right place, correct proportions?
- Are the fonts, colours, and spacing consistent with the brand guidelines?
- Are all the sections from the scope present? Nothing missing?
- Do interactive elements (dropdowns, accordions, sliders) work as expected?
Be specific in your feedback. "The hero looks wrong" is hard to act on. "The hero text on mobile is overlapping the image at the bottom" gives the developer exactly what to fix.
Test the key user flows
Beyond browsing, test the specific things customers will actually do:
Buying: Add to cart, go to checkout, complete a test order with a real card (then refund it). Confirm you receive an order confirmation email. Check the email looks correct — right branding, right content, right product details.
Searching: Use the search bar to find a product. Check that results are relevant and the search page looks correct.
Creating an account: Sign up for a customer account. Check the account dashboard looks correct and shows order history.
Using discount codes: If discount codes are part of your business, test one in the checkout. Confirm it applies correctly and the order total updates accurately.
Accessing key pages: Navigate to your about page, contact page, returns policy, and any other pages that should exist. Confirm they're live and accessible.
Run a speed check
Go to pagespeed.web.dev, paste the staging URL, and run the analysis. You want the mobile score to be above 70 before launch, and ideally above 85. If it's below 60, flag it with your developer before approving the work.
A low score on a staging site often indicates something that will be worse on the live site — a large unoptimised image, a slow app, or a render-blocking script that the developer needs to address before delivery.
Check the things clients typically miss
These are the areas most non-technical clients forget to review:
404 pages: Type a nonsense URL on the staging site (e.g., yourstore.myshopify.com/doesnotexist). Does it show a custom 404 page that matches your brand, or Shopify's default? The default 404 is fine but a branded one is better.
Empty states: What happens when your cart is empty? What does a collection page look like if you filter it down to zero results? These edge cases often get forgotten in development and look terrible when customers hit them.
Forms: Submit your contact form with a real message. Check you receive it. Submit it with missing fields — does it validate correctly and show useful error messages?
All variants: On your product pages, click through every variant — every size, every colour. Check the price updates correctly, the images swap to the right variant image, and sold-out variants are clearly marked.
Footer and legal pages: Is your privacy policy linked? Terms of service? Returns policy? These seem trivial but they matter for trust and in some markets are legally required.
How to give useful feedback
When you find issues, specific feedback gets faster, better fixes than vague feedback.
Useful feedback: "On mobile, the product title on the Women's Coat product page is being cut off after the first line and showing an ellipsis. It should show the full title." Screenshot included.
Less useful feedback: "The product pages look a bit off."
The best way to share feedback is with annotated screenshots — use tools like Loom (video), CleanShot, or simply a screenshot with arrows drawn on in preview. One piece of feedback per issue, with a screenshot showing exactly what's wrong, is the format that gets things fixed fastest.
When to approve and when to push back
Approve the work when: everything in the brief is present and correct, the key user flows work end-to-end, the mobile experience is solid, and the speed score is acceptable.
Push back when: something agreed in the scope is missing, the mobile experience has obvious problems, the checkout flow is broken, or the speed score is below 60 and the developer hasn't explained why.
Don't approve work that has unfixed issues just because the deadline feels urgent. Launching with broken checkout or mobile problems costs more than a short delay to fix them.
