Your whole team, experimenting on the real product. Remix lets any team member spin up a variant of your actual product: a safe, sandboxed copy you shape by prompting. No setup, no risk to production. Explore ideas side by side as a team. Like where two variants are headed? Drag one into the other to merge them. When an idea is ready, open a PR straight to GitHub. Every prompt is recorded, so reviewers see exactly how it was built and a live link lets anyone test before a single line hits main.
Hey Product Hunt!
We are launching Remix today.
We believe the best idea for a product rarely comes from the people allowed to build it. A designer, a PM, a support rep sees exactly what should change, then waits weeks for engineering time, if it happens at all. That wait is where most good ideas quietly die.
The coding itself has become much easier with AI. Everything around it is still hard: setting up the project, running it, previewing it, keeping up with the main codebase, reviewing the work, and getting it shipped.
Remix handles all of that, and makes it multiplayer. Anyone on the team works on a safe, live copy of the real product and makes changes by describing them. Every remix gets its own sandbox and live preview, and it's checked against your design system, security, and compliance rules before it goes anywhere. Engineering moves up to architecture and approval: they see the prompts, review a clean pull request, and keep the final say.
One of our early teams had a designer rework their app's empty states, something that had sat in the backlog for months. She prompted it, previewed it, and it shipped the same day through a normal PR review.
We're working closely with early teams right now, and I'd love your feedback: what product changes keep getting stuck at your company because the person who spotted them can't build them?
I'll be here all day answering questions. Thanks for checking out Remix.
Report
@heshamghandour The sandbox is what I'd want to understand before handing this to a support rep or a designer. When someone spins up a live copy of the real product, what is it running against: a snapshot of production data, seeded fixtures, or something synthetic?
@clement_avq Good question, and the honest answer is: none of the three by default. The sandbox runs the real app off the branch, what it talks to is a config decision you make, not something Remix picks for you.
For the case you're describing (support rep or designer poking at a live copy), I'd point it at a dev or staging backend.
They get a fully clickable version of the real product, and nothing they do touches production data.
The other options are there if you want them: point it at production if that's genuinely what you need, host a backend sandbox on Remix too so a frontend sandbox talks to its own isolated backend, or upload a build running on synthetic data.
Happy to walk through how you'd wire it up for your setup.
Report
@heshamghandour Makes sense, thanks. One follow-up: is the backend target locked at the project level by whoever connects the repo, or can whoever creates a remix repoint it themselves?
@clement_avq Project level sets the default, and every remix inherits it. But each remix is its own VM sandbox, so you can repoint an individual one without touching the project config.
Think of it as a preset rather than a lock. Env vars are editable in settings, and you have full terminal access on the sandbox if you want to go further.
Report
@heshamghandour Understood, so it's a default rather than a boundary. Given the target user is the non-engineer, is there a path to enforcing the target per role, and is repointing a sandbox visible to whoever owns the project?
Report
I really like this, accelerating ideas -> prod while also giving the engineer greater visibility to see the whole process before the PR even lands, brilliant
Remix
@heshamghandour The sandbox is what I'd want to understand before handing this to a support rep or a designer. When someone spins up a live copy of the real product, what is it running against: a snapshot of production data, seeded fixtures, or something synthetic?
Remix
@clement_avq Good question, and the honest answer is: none of the three by default. The sandbox runs the real app off the branch, what it talks to is a config decision you make, not something Remix picks for you.
For the case you're describing (support rep or designer poking at a live copy), I'd point it at a dev or staging backend.
They get a fully clickable version of the real product, and nothing they do touches production data.
The other options are there if you want them: point it at production if that's genuinely what you need, host a backend sandbox on Remix too so a frontend sandbox talks to its own isolated backend, or upload a build running on synthetic data.
Happy to walk through how you'd wire it up for your setup.
@heshamghandour Makes sense, thanks. One follow-up: is the backend target locked at the project level by whoever connects the repo, or can whoever creates a remix repoint it themselves?
Remix
@clement_avq Project level sets the default, and every remix inherits it. But each remix is its own VM sandbox, so you can repoint an individual one without touching the project config.
Think of it as a preset rather than a lock. Env vars are editable in settings, and you have full terminal access on the sandbox if you want to go further.
@heshamghandour Understood, so it's a default rather than a boundary. Given the target user is the non-engineer, is there a path to enforcing the target per role, and is repointing a sandbox visible to whoever owns the project?
I really like this, accelerating ideas -> prod while also giving the engineer greater visibility to see the whole process before the PR even lands, brilliant