infini-creators

byHeartless Beast

You are building a production‑style web application called “Vibe‑Video Prompt Market (VPM)”. User’s goal: Creators can upload and sell cinematic AI‑video prompt packs. Buyers can browse packs, buy them with credits, and copy prompts to use in AI‑video tools like Runway, Pika, or HeyGen. This must be a real, maintainable web app, not a toy demo. Stack and constraints: Frontend: React + Tailwind CSS (no Next.js initially; use create-react‑app style). Backend: Node.js + Express. Database: SQLite (for local dev); later this can move to PostgreSQL but keep schema simple. Auth: simple email + password (no OAuth yet). No “magic” frameworks or experimental tools; stick to widely used libraries. Data models: User id (primary key) email (unique) passwordHash (use bcrypt) role: 'creator' | 'buyer' credits: number (default: 100) PromptPack id (primary key) title: string description: string tags: string[] (e.g., “K‑fashion”, “Bollywood”, “pet”) priceInCredits: number (must be ≥ 0) creatorId (foreign key to User) createdAt Purchase id buyerId (foreign key to User) promptPackId (foreign key to PromptPack) creditsUsed: number purchasedAt Key business rules: Users must sign up / log in before using the app. Only users with role: 'creator' can upload prompt packs. When a buyer buys a pack: The backend must check credits first (user.credits ≥ priceInCredits). If yes: Deduct credits from buyer. Create a Purchase record. If not, return an error. No client‑only credit logic. Always enforce credits on the server. Pages and features (v1): Landing page (Home) Simple header: “Vibe‑Video Prompt Market”. Short description: “Buy and sell cinematic AI‑video prompts.” Buttons: “Login / Sign up”. Signup / Login Email + password. On signup, default to role: 'buyer'. No Facebook/Google login for now. Marketplace page All logged‑in users see a list of PromptPack items. Each item shows: Title, description, tags, priceInCredits, creator. Simple search/filter by tags (e.g., type “K‑fashion” → only matching packs). “Buy” button per pack. Buy pack flow When buyer clicks “Buy”: Call a backend API endpoint (POST /api/packs/:id/buy). Show loading → success message → “Copy prompt” button (for the pack’s title + description). Dashboard For creators: List of their uploaded packs. Button to “Upload new pack” (form: title, description, tags, priceInCredits). For buyers: List of packs they bought. Code structure (folder structure): Client (React): src/pages/HomePage, LoginPage, MarketplacePage, DashboardPage. src/components/PromptPackCard, PromptPackForm, LoginForm, etc. src/services/api.js – API calls to backend. Server (Node/Express): routes/users.js, routes/packs.js, routes/purchases.js. controllers/users.controller.js, packs.controller.js, purchases.controller.js. models/ – Sequelize or plain SQL models for User, PromptPack, Purchase. middleware/auth.js – protect routes that require login. Quality and safety rules: Write clear, self‑documenting code: Function names that describe what they do. No anonymous functions in critical paths. Add basic validation: Email format, non‑negative priceInCredits, non‑empty title/description. Add error handling for: Invalid login, insufficient credits, invalid pack ID. Do not invent extra features (e.g., chat, live video previews, payments with Stripe). If you want to add those later, ask the user explicitly. What you must NOT do: Do not auto‑generate complex UI libraries or random frameworks. Do not skip auth or treat credits as a frontend‑only number. Do not couple unrelated features into the same file. Do not write overly clever or “magic” code that’s hard to debug. Now, generate the full codebase for this Vibe‑Video Prompt Market app: client/ React app with the pages and components described. server/ Express backend with the routes, controllers, and models. A simple README.md explaining how to: run npm install in both folders, start the server, start the client, and test basic flows (signup, login, create pack, buy pack). Do not just write a rough idea. Do write complete, production‑style code (with comments where needed) that I can run and maintain as real software.