The story of how this project came to be, and where it might go.
Standing on the shoulders of giants.
The foundation for this project is screenshot-to-code by abi—a brilliant open-source tool that pioneered AI-powered design-to-code conversion.
The original project is excellent—it does exactly what it promises and does it well. But for developers who just want to try it out, experiment with different designs, or use it occasionally, the Docker setup becomes a barrier.
So I created a hosted version that just works. No Docker, no servers, no configuration files. Just visit a URL and start generating code. Bring your own API keys so you only pay your AI provider directly—zero markup, no subscription, no middleman.
Along the way, I added features I personally needed: better asset handling during iterations, improved file exports for real workflows, and secure session-based encryption for API keys.
This project exists to remove friction, not to compete with the original. All the core magic—the AI-powered conversion—comes from abi's brilliant work.
A timeline of features and the stories behind them.
The problem: Docker setup is a barrier. People want to try the tool, experiment with different designs, test various approaches—but setting up infrastructure stops them before they start.
The solution: Just host it. Let people visit a URL and use it immediately. No Docker, no servers, no configuration files. Bring your own API keys (BYOK) so you only pay your AI provider directly—no markup, no subscription, no middleman.
The result: Test immediately. Try it with different designs. Experiment freely with zero commitment.
The vision: When you screenshot a real page, you want to use the actual images from that page. When you export from Figma, you want the real assets—not placeholder rectangles.
What I built: Multi-image upload where you provide a screenshot plus separate asset files (logos, photos, icons). The AI references these throughout generation, and crucially, they persist during the entire iteration process. Make updates and your assets stay correctly attached.
Why it matters: Your generated code can be closer to final, production-ready output—not just a prototype with broken image references.
The goal: Make the pipeline from design to working prototype as short as possible. Yes, we could export everything as one giant component, but that creates an unwieldy blob developers can't work with.
The approach: Better file naming, proper extensions (.tsx for React, not .html), and thoughtful component structure. Small, focused components that are parts of the final design can be downloaded directly as proper TypeScript files.
The impact: Developers can actually use the generated code. Drop it into a project, refine it, ship it. Not just "look at this cool demo."
The ethical dilemma: Users bring their own API keys. I could store them in a database like most services do. But is that ethical? Those keys give access to paid services—storing them felt wrong.
The solution: JWE (JSON Web Encryption) with server-side encryption. Your API keys are encrypted into session tokens that only the server can decrypt. They never touch a database. They can't leak from storage. They exist only for your session.
The principle: Security was non-negotiable. If you trust me with your keys to use my hosted service, I owe you bulletproof protection.
The milestone: Migrated from Vite to Next.js, set up CI/CD, implemented proper deployment infrastructure. Some pages can now be cached efficiently (though admittedly, nothing caches better than static HTML—the previous approach had that advantage).
The trade-off: Lost some caching simplicity, but gained a future-proof setup that makes adding new pages easier. Server-side rendering capabilities. Better SEO for marketing pages. A foundation that can grow.
The reality: This was infrastructure work—not flashy, but necessary to run a reliable hosted service instead of just a Docker container.
Ideas in the backlog. No promises, just possibilities.
For those who want zero setup: A paid tier where you don't need to manage your own API keys. Just pay a simple subscription and use the platform keys. No tracking usage, no worrying about costs.
For supporters: A tip jar for those who find value in the free tier and want to support development. No pressure, purely optional.
Beyond what the original offers—perhaps Svelte, maybe Angular if there's demand. Community-driven additions.
Better ways to manage, preview, and reference uploaded assets throughout the generation process.
Simple dashboard showing generation count and estimated costs. Helpful for budgeting your API usage.
In-app way to send feedback, report bugs, or suggest features. Maybe integrated with GitHub as external storage, or maybe it's time for a real database.
The vision: Right now, the system generates one monolithic component. But what if it could output multiple small, focused components? When a page has distinct sections—header, hero, features, footer—each could be its own component.
The challenge: Refinement would be tough. How do you iterate on individual components while maintaining the whole? How do you let users edit section A without breaking section B? The UX complexity is real.
The payoff: Stitching together small, reusable components to form a working view—that would be genuinely useful for production workflows. Worth exploring, but no timeline yet.
What I wanted: Upload a screenshot and have the AI automatically extract logos, icons, and images as separate assets. Clean separation between structure and content.
Reality check: I built it. It was difficult. The results weren't reliable enough. Sometimes it worked beautifully, sometimes it mangled assets or missed them entirely.
Shelved for now. Manual asset upload works well enough, and perfect is the enemy of good. Maybe one day with better models, but not a priority.
Have feedback? Found a bug? Want a feature? This is a community project shaped by what people actually need.
No setup, no commitment. Just ideas turning into code.
Start Creating