Designers, your "developer handoff" is the dumbest workflow in tech.
You spend two weeks perfecting a screen in Figma.
Then you hand it to an engineer who rebuilds it from scratch, gets the spacing wrong, ships it in three sprints, and somehow it looks worse than the mockup.
I built Maker because I was tired of this.
It's an infinite canvas where you build real websites by talking. You describe it, it ships it, real HTML, real CSS, real code that lives on your Mac. Click any element, tell it what to change, watch it happen. Undo anything. Own everything.
No handoff doc. No "can you nudge that 4px." No begging for a billing cycle to export your own work.
Framer and Webflow sold you a beautiful prison. You design inside their walls, on their terms, and the second you stop paying, it's gone.
Maker hands you the keys instead of another cage.
Here's the uncomfortable truth nobody in design tooling wants to say out loud: The handoff was never about quality. It was about keeping designers dependent. That era is over.
You don't need permission to build anymore. You don't need to "learn to code." You need taste, and you already have it.
The walled garden is on fire.
If you're a designer who's done waiting for an engineer to make your work real, comment MAKER and I'll send you in.
Grass
Hey Product Hunt 👋 I'm Sunny, the maker of Maker.
I'll say the thing everyone in the design-to-dev pipeline is too polite to say: the handoff is broken. You spend days perfecting a Figma file, hand it off, and watch it ship looking 70% right, because a mockup was never the real thing. It was a picture of the real thing.
Design engineers already figured this out. They don't draw the product and pray. They build it. So I made the tool I wanted for that:
🎨 One infinite canvas. Every page of your real project is a live, clickable preview, pan, zoom, and see your whole site as a map, not one tab at a time.
👉 Point at what's wrong. Click any element on the canvas and describe the change, it edits your actual code, not a throwaway prototype.
⚙️ It runs your real project. Maker starts your dev server, finds your routes, and drops each one onto the canvas automatically. Astro, Next, Vite, whatever you build with.
🛡️ You stay in control. Approve every change, or let it run and undo any step. It's your code the whole time.
It's an early alpha for Apple Macs, and I'd genuinely love to be told I'm wrong. So: is the design-to-dev handoff actually fine and I'm just bad at it? Or have you felt this pain too? I'm here all day, roast it, question it, ask me anything. 🙏
This hot take is honestly not that hot :)
We felt this a lot while building our product. the hard part is not making something look good once in a mockup, it is getting the actual product to feel right after states, edge cases, responsiveness, real content, and implementation details show up.
The “picture of the real thing” line is strong. Figma is great, but there is always a moment where the real product becomes the source of truth and the mockup starts falling behind. Maker feels interesting because it starts from the actual running project, not an imaginary clean version of it.
Curious how it handles existing design systems and messy codebases. if a project already has components, tokens, and layout conventions, does Maker learn to work inside those patterns or does it mostly make direct changes?
Grass
@andrasczeizel The mockup looking good once is the easy part. States, edge cases, real content breaking your grid, responsive behavior nobody mocked, that's where the 70% actually leaks. And yeah, there's always that moment the running product becomes the source of truth and Figma quietly turns into documentation of a past decision. Maker just tries to make that moment day one.
On your question: it edits your real files, so it's working inside your existing components, tokens, and conventions, not generating a clean parallel version. It does a good job with all those context to create new pages or sections with the same design system. It's strongest when you point at a specific element and direct the change.
how does this actually handle routing for apps that use something like dynamic params or middleware-heavy setups? curious if it breaks down beyond the basic happy path
Finally tried this on a side project and pointing at a broken layout to edit the actual component felt like cheating. The route mapping saved me an hour of clicking around.
Pointing at a layout and having it edit the real code feels like cheating in the best way. The auto-mapped routes saved me from the usual config grind.