From Prototype Feedback to Acceptance Tests
While trying a prototype, stakeholders can point to a problem and state the expected outcome, giving the team an acceptance test and a constrained fix to review immediately.
When a nontechnical stakeholder tries an AI-generated prototype for the first time, they can often immediately say, “It should not navigate like that,” or “The customer status should appear here first,” yet struggle to turn that reaction into a development task. A click-to-comment control in the shared preview lets them select a button, table row, or modal and describe what they expected instead. The product freezes the page structure, sample data, and the interaction path that led to that screen.
It then rewrites the frozen feedback as an executable acceptance test. If a stakeholder selects “Submit” and says, “Do not close the form when the phone number is blank,” the test captures the current inputs, the click action, and the interface state that should remain. Developers can add edge cases and, once it is approved, hand it to a coding agent. Feedback no longer floats in a chat thread detached from the page that prompted it.
The agent changes code only in a separate branch and must make the new version pass that test. A review room presents the original and fixed versions side by side to the person who raised the issue, who can try them again and decide whether to accept the fix. Failed fixes retain their failure screen and logs for a developer to take over, rather than silently overwriting the prototype.
The first version can support web prototypes, fixed sample data, and Playwright acceptance tests. It does not treat every spoken remark as a requirement; only page states confirmed by the stakeholder enter the code-change workflow.
Why now
As observed on August 29, 2026, Play with Putty ranked No. 2 in Product Hunt’s new-product feed and promotes real-time collaborative vibe coding. S1 As nontechnical stakeholders are brought directly into shared building and tryouts, specific disagreements about interactions surface earlier, making it more urgent to turn verbal reactions into verifiable changes.
Target user
The core users are founders, operations leads, and client-side decision-makers who own business outcomes but do not write development tasks. They are trying a clickable AI prototype and have just encountered navigation, field-state, or modal behavior that does not match expectations. With the page, sample data, and interaction path still in view, their verbal feedback is most concrete. If they wait until after the meeting to organize it, the feedback can easily collapse into “this is wrong” or “the experience feels bad,” requiring developers to ask follow-up questions all over again.
Minimal entry point
Keep the first release within controllable web previews and fixed sample data. An embedded annotation script records the selected element, form values, page URL, viewport, and steps taken to reach the page, then asks the stakeholder to add one sentence describing the expected result. The server organizes this material into a Given-When-Then draft for approval. Once confirmed, it generates a Playwright test: Playwright codegen can record clicks and form fills, while its test agent can generate test files from a plan. S2 Code changes run in a temporary Git branch and isolated preview. The results page retains screenshots, traces, console logs, and links to both versions. The first release excludes production data, native mobile apps, and simultaneous multi-user editing.
Punching above its weight
Early users are most likely small studios rapidly building AI prototypes for clients and founder teams without a dedicated product manager. Publish a public tryout template with a broken form, letting visitors complete the full flow themselves: flag an issue, generate a test, and review the fix. Then build a GitHub App that writes approved tests and fix branches back to the repository. Each public case can show the original feedback, failure screen, and passing result, making it easy to share in prototype-tool and developer communities.
Competitors & gaps
- Marker.ioGoogle
- Marker.io already lets reviewers submit visual feedback directly on a webpage. It can attach annotated screenshots, comments, session replays, and technical details, then send reports into the team’s existing workflow. S3 That solves the cost of locating where a problem occurred and works well for design reviews and bug reports. The gap is the execution path after feedback is submitted: its public capabilities focus on creating reports, not turning a reviewer-approved expected state into an executable test. It does not require a fix to pass that test in an isolated branch, nor does it return the original and fixed versions to the same reviewer for verification. This product should avoid rebuilding general-purpose annotation and focus on the closed loop from feedback to test to code change to re-verification.
- Leapwork PlayGoogle
- Leapwork Play already supports generating tests from natural language, recording browser actions, and editing and running tests in a shared workspace. It can also import existing Playwright scripts and connect to coding agents through MCP. S4 These capabilities target QA professionals, SDETs, developers, and technical testers, with more complete test-asset management. The gap is how a nontechnical owner initiates a request from the page they are actively trying. Its public workflow starts with a test description, recording, or existing materials, rather than emphasizing selecting a disputed element and stating the expected outcome. Nor does it make the person who raised the feedback the fix’s acceptance reviewer. This product can stay focused on the prototype stage, avoiding the setup burden of a full testing platform while preserving page state and the path used to reach it.
How it makes money
Charge monthly per active project, with plans that include a set number of acceptance tests, branch runtime, and result storage. Bill excess runs by usage; external reviewers do not need paid seats.
The case against
Freezing a page state is much harder than taking a screenshot. Dynamic APIs, randomized data, login state, and third-party components can make the same feedback difficult to replay. If generated assertions depend too heavily on DOM structure, minor revisions will create false positives and teams will quickly stop trusting the tests. Saving form values, page structure, and logs also creates sensitive-data governance costs. Isolated branches, preview environments, and browser execution will consume compute on an ongoing basis. Harder still is turning a vague expectation into a single assertion: a wrong test can force the agent to implement the wrong behavior. The condition for continuing is to first prove test stability on fixed-data prototypes and make it easy for developers to revise assertions.