Running stakeholder QA on staging without a spreadsheet

Most startup teams run QA on staging the same way: someone creates a spreadsheet, shares it with the founders, product, design and marketing, and asks everyone to "add issues here". By the second release the sheet has 140 rows, half of them duplicates, and nobody knows which ones were fixed in which build.

Here's a lighter process that works for teams shipping every week or two.

Why the spreadsheet breaks

• No context. "Button overlaps on checkout" doesn't say which screen size, browser or account state.
• No link to the release. A row from two builds ago looks exactly like a new one.
• No clear status. "Fixed?" in a comment column isn't a workflow.
• Copying into the tracker. Someone has to re-type every row into Jira or Linear, and the two drift apart.

A better process in five steps

1. Treat each staging release as a version

When a build is ready for review, give it a number (v12, or the release date) and tell reviewers which one they're looking at. Feedback then belongs to a version, and old issues don't get confused with new ones.

2. Give reviewers a focused brief

"Please review the new onboarding flow on mobile: sign-up, the first project, and the empty states" gets far better feedback than "have a look at staging". Name the flows and the devices.

3. Capture issues where they happen

Ask reviewers to report issues on the page itself, with the element, the page address, the browser and the screen size captured automatically. Engineers can then reproduce the issue without a follow-up chat.

4. Triage once a day

One person, usually the PM, sets a priority on each new issue (low, medium, high or critical), assigns it, and closes duplicates. Fifteen minutes a day is enough for most teams.

5. Close the loop with the reviewer

When an issue is fixed, move it to "awaiting review" so the person who reported it can confirm on the next build. Only then is it resolved. This one step stops most "I thought this was fixed" arguments.

Who signs off

Decide before the release who gives the final go-ahead: usually the PM for product flows, and design for visual changes. Write it in the release checklist. Everyone can report issues, but a release needs one clear yes.

Doing this in MarkFeed

MarkFeed is built for this loop. Add the MarkFeed script to staging (or share a review link), and reviewers click on any element to report an issue. Each report includes a screenshot, the page, the browser, the OS and the screen size. Issues land on a board with Open, In Progress, Awaiting Review and Resolved columns, with priorities, assignees and internal notes your reviewers don't see. Each website keeps its versions, and approvals are recorded per version.

The script works on pages behind a login too, so reviewers can test signed-in flows. See MarkFeed for product teams or the task board.