TryCase

As a solo dev shipping an iOS app, the final manual-verify step is exactly where my releases stall — I'm the QA team of one, and "done" from an agent usually just means "it compiled." The disposable box per agent is a smart way to move that check off my laptop. Does it handle mobile/app flows (simulator or a device) yet, or is it web + CLI apps only for now?

This maps to the messy part of agent coding for me: not the patch itself, but proving it ran in a clean environment. The useful constraint is keeping the proof lightweight enough that agents actually include it every time.

Love how the screenshots and recordings come back with the diff already attached, makes verifying what the agent actually did way less of a guessing game.

the disposable linux envs actually working from a single prompt blew me away, screenshots and all. finally lets the agent go end to end without me babysitting every shell command.

how does it handle cleanup of those disposable environments when an agent spins up a bunch in parallel, anything to worry about resource-wise?

finally something that lets my agent actually run the code instead of me playing QA. tried it on a small flask app and got back screenshots plus a clean diff, which honestly saved me a whole round trip.

Congrats on the launch, this is a real problem. My question is more about the iteration loop than the verification side - if an agent fails, tweaks the code, and needs to test again, does it get a brand new disposable box each time, or does it reuse the same one until the task is done? Fully fresh every retry sounds cleanest for isolation but on a repo with a slow install/build step that could add up fast if the agent is iterating 10+ times on one bug.

I’m curious about the differences between GPT-5.5 browsing and testing and TryCase. What makes TryCase unique, apart from just screenshots and videos? Thank you

How do you handle state between runs if the agent needs to verify something like a running database or queued background jobs from a previous step?

'Return verified code instead of asking you to test manually' is the exact gap. My coding agent writes the fix, then I'm the one clicking through the app like it's 2015. The agent proving its own work with screenshots and recordings flips the trust equation completely. How isolated are the environments - can it safely test against a copy of production data? Congrats on the launch.

congrats on the launch ben. the port collision thing you describe hit me the first time i let two agents run dev servers at once, so the throwaway box approach makes a lot of sense. one thing i'm curious about: booting an app end to end usually means real env vars, api keys, db urls. where do those secrets live while a sandbox runs, and does teardown wipe them for good?

the 'done only after it actually ran and verified' bar is the right one. do you surface the failed attempts too, or just the final passing proof?

"agents should only say done once they've actually run and verified the work" is exactly right and it's the thing i keep running into with my own multi-agent setups - an agent will confidently report success based on its own transcript when the thing it was supposed to do never actually happened underneath. running multiple worktrees locally does turn into port collisions and reused browser sessions pretty fast like you said. does the screenshot/recording proof get attached anywhere the agent itself can't fake or reword, or is it still on me to actually look at the video rather than trust the agent's summary of it?

Love the framing around agents only saying done after screenshots/video proof in an isolated env — that is exactly the gap when running multiple worktrees locally. Good luck with the launch.

Hey Product Hunt,I’m Ben, and I’m building TryCase.This came from my own workflow. I’ll often have a bunch of agents running at once across different worktrees, each trying changes, spinning up the app, testing, iterating, taking screenshots, or recording proof.That gets messy quickly. My laptop becomes the bottleneck, ports collide, installs overlap, browser sessions get reused in weird ways, and I still end up doing a lot of the final verification myself.So I built TryCase to give each agent its own disposable Linux environment in the cloud. The agent can run the app, test the change end to end, capture screenshots or video, and come back with proof instead of just code.It’s also useful for longer-running tasks. You can give an agent a goal, let it work inside a clean disposable environment, and ask it to come back with screenshots, logs, and recordings. Secrets can be passed in deliberately, and each run is isolated from your laptop and from other agents.TryCase is still early, but the goal is simple: agents should only say “done” once they’ve actually run and verified the work.It’s easy to try. Just ask your coding agent to use TryCase at trycase.dev:- Fix this bug, test it end to end with TryCase, iterate until it works, and send me screenshots and a video recording as proof.- Implement this feature, run the app in TryCase, iterate on any failures, and prove it’s working with screenshots, logs, and a recording.- Use TryCase to run this repo in a clean environment, verify the main flow, and show me what the app looks like.- Test this branch in TryCase, find anything that breaks, fix it, and prove the final version works.- If manual login is needed, use desktop mode and give me the take-control link.I’d love feedback from people using Codex, Claude Code, Cursor, or other coding agents. What would make you trust an agent’s “done” more?