ramjit-soren/generative-ai-apps

1. This repository is a catalog of many independent AI SaaS templates, not a single application. The root README.md is the product catalog, and each subfolder under ai_agents, image_generation, video_generation, beauty_fashion, ecommerce, home_real_estate, portrait_avatar, writing_content, and platforms is a standalone deployable product.

2. Most templates share the same SaaS spine: a Next.js App Router frontend in src/app, API routes in src/app/api, reusable UI in src/components, and server-side helpers in src/lib. That shared shape is the main architecture pattern across the repo.

3. The typical data boundary is browser → Next.js route handler → service layer → database / external AI provider. The UI pages drive actions like login, pricing, gallery, dashboard, and creation views; the API layer performs auth checks, billing checks, generation requests, and persistence.

4. Persistence is usually Prisma-backed. Each app has its own prisma/schema.prisma, a prisma.config.ts, and src/lib/prisma.js, which means the database model is local to each template rather than shared across the repo. The README confirms PostgreSQL is the standard backing store.

5. Authentication is centralized around NextAuth with a Google OAuth-style login flow. The auth entry point is usually src/app/api/auth/[...nextauth]/route.js, supported by src/lib/auth.js, and the UI exposes login and protected dashboard/gallery areas.

6. Billing is a first-class subsystem. Templates expose checkout endpoints and Stripe webhook handlers, with billing logic factored into src/lib/services/billing.js and Stripe client setup in src/lib/stripe.js. The usual flow is: user initiates checkout, Stripe confirms payment, webhook updates account state or credits in the database.

7. AI generation is usually isolated behind feature-specific route handlers and a service wrapper. Common patterns include /api/generation, /api/upload, /api/download, /api/creations, plus feature routes such as /api/headshot, /api/logo, /api/tryon, /api/fitness, /api/seedance, or /api/generate. These endpoints typically store a job record, call MuAPI or another model provider, and later return status or artifacts.

8. Many products use asynchronous job polling rather than synchronous generation. Evidence in the tree includes status endpoints like /api/headshot/status, /api/generate/status, /api/banana/status, /api/fitness/status, and /api/seedance/check-status. This suggests a job lifecycle of submit → persist job id → poll status → materialize result in gallery/creations.

9. The UI layer is mostly shared layout plus vertical-specific feature components. Common pieces include Navbar, Footer, Providers, and domain-specific widgets like templates, sliders, forms, editors, selectors, credit badges, and canvas-like views. This keeps the top-level app shell consistent while each niche product swaps in its own generation UX.

10. There are some higher-complexity platform projects that break the usual single-app pattern. platforms/Open-Generative-AI adds an Electron shell, local inference modules, and a separate packages/studio UI package; platforms/Open-AI-Design-Agent and platforms/Open-Poe-AI split into a Next.js client plus a Python server; platforms/Open-Generative-AI also includes model catalogs, workflow routes, and local model management. These are multi-runtime architectures rather than standard SaaS templates.

11. The main external service boundaries are Stripe for payments, MuAPI for model access and async generation, and Google OAuth through NextAuth. Some niche templates add their own provider-specific routes, but the repo-wide architecture is still built around those three integration points.

12. For an architecture diagram, the key takeaway is that this repo is a factory of self-contained SaaS products with a common reference architecture: Next.js frontend, API routes, Prisma/Postgres, auth, Stripe billing, and AI-job orchestration. The important variation is whether a template stays within that standard stack or adds an extra backend/runtime layer for local inference, desktop packaging, or specialized processing.