5
10 Comments

I built an AI platform that generates production-ready React & Node apps from a prompt

Type a prompt, get a full React web or mobile app. Real code, ZIP export, deploy anywhere. White-label ready for freelancers & agencies. Built with Next.js, Claude API, Supabase. Live at promptgear.dev , no sign up, first 100 get a free generation.

posted toAvatar for product PromptGear
PromptGear
  1. 1

    cool build. one thing that usually decides retention for prompt-to-app tools is first deploy success rate, not codegen quality.

    id track 3 numbers: time to first live deploy, percent of users who connect auth+payments in first session, and percent who ship a second app in 7 days. those 3 tell you if this is becoming workflow infra vs just a demo tool.

    1. 1

      Really good point and exactly the kind of metric I need to focus on.

      Right now, deploy to Cloudflare Pages is one-click, so time from prompt to live site is cca. 3 minutes. I'm tracking auth + Stripe connection rates but don't have enough data yet for solid percentages. The "second app in 7 days" metric is great :-) I wasn't tracking that specifically, adding it now.

      This kind of feedback is exactly what separates a shiny demo from real workflow infra. Appreciate it.

  2. 1

    Interesting direction. As a founder, tools that reduce build time are great, but the real value shows when they also help with iteration speed. Being able to test ideas quickly and refine based on user behavior has been far more important for us than just shipping faster.

    1. 1

      Thanks Predrag! Totally agree, iteration speed is where the real value is. That's why we built a visual editor on top of the generated code. You generate the base, then tweak text, colors, images, layout all without tokens, unlimited free edits. So you can ship fast AND iterate fast based on feedback.

  3. 1

    This is impressive — getting production-ready output instead of just demos is the real challenge.

    Curious where you see most of the real use case today: freelancers spinning up client MVPs, or founders validating ideas quickly?

    Also, how are you handling things like auth, payments, and environment config in the generated apps? That’s usually where “AI generated” projects break in real life.

    1. 1

      Great question! Right now it's a mix of both. Freelancers using it for client MVPs and founders validating ideas quickly. The sweet spot is agencies who need to deliver multiple projects fast.

      For auth and payments users can connect their own Supabase for user accounts and Stripe Checkout directly in the generated app. Environment config is handled through our dashboard, so the generated apps come ready to deploy with all integrations wired up.

  4. 1

    Congrats! 🎊. Nice stack choice. Supabase plus Stripe plus Cloudflare keeps the surface predictable, and good to see you’re not storing card data directly.

    Quick security questions:

    1. Since you store generated websites and project content, how are you isolating projects between users at the database level?

    2. Are Anthropic requests strictly server side with no API keys exposed to the client?

    1. 1

      Thanks! Good questions:

      1. Project isolation every project is scoped to the authenticated user's ID at the database level. Row Level Security (RLS) in Supabase ensures users can only access their own projects. Guest projects are stored client-side only (localStorage) and never touch the database.

      2. API keys yes, all Anthropic requests are strictly server-side. No API keys are ever exposed to the client. The frontend talks to our Express backend, which handles all AI calls securely.

      1. 1

        Great to hear you’re using RLS properly. Scoping everything to the authenticated user at the database layer is the right foundation. Keeping guest projects client side only also keeps the server surface smaller.

        Server side only AI calls is the correct move as well. No exposed keys, no direct model access from the browser. That removes a whole class of abuse.

        Since you’re already thinking this way, one thing we often see later is logic flaws between project IDs and user IDs in complex flows, not just direct reads. Worth periodically testing for IDOR and cross project access edge cases as features grow.

        We’re a security team and built Nautillo Pro to simulate these kinds of real world attack paths against live apps. If you ever want an external check before a major release, you’re welcome to try our web attack simulator. There’s a free version for solo founders, so you can run a simulation monthly and stay ahead of surprises.

        Nice work on the architecture. Keeping the surface predictable early pays off.

        1. 1

          Thanks for validating the architecture - IDOR and cross-project access is exactly what I'm focusing on in the next security pass. RLS policies are scoped per user, but you're right that as features grow, periodic testing for logic flaws between project and user IDs is essential. Nautillo Pro looks interesting, I'll check out the free version. Appreciate the tip!