venkatesh5650/digital_businesscard_platform

1. This is a Next.js App Router application centered on digital identity cards, with three major surfaces: a public marketing site, a user dashboard, and an admin console. The README is generic, but the file tree shows the real product shape.

2. The public-facing layer lives in src/app/page.tsx, src/components/landing, and src/app/[slug]. The root pages are marketing content, while the dynamic /[slug] route is the public card/profile page rendered for each card identity.

3. The card experience is a distinct subsystem. src/components/card contains the public card renderer, lead capture, social links, payment panel, and reusable fragments. src/components/card/templates and src/data/templates.ts indicate multiple card themes, with src/data/coverPresets.ts and src/data/dummyCard.ts supporting preview/default content.

4. Card data is exposed through a dedicated public API at src/app/api/vcf/[slug]/route.ts, which likely generates downloadable contact data. That makes the card page both a visual profile and a distribution channel for contact info.

5. Auth is handled as a separate boundary: src/app/api/auth/[...nextauth]/route.ts, src/auth.config.ts, and src/lib/auth.ts define the authentication stack, while src/app/auth/signin, register, and error provide the user-facing entry points. src/middleware.ts likely enforces route protection and/or maintenance gating.

6. The authenticated user workspace is under src/app/dashboard. It includes the main overview, card editor (dashboard/card/[id]), leads, payments, and legal pages. Client components such as DashboardClient.tsx, CardEditorClient.tsx, and LeadsClient.tsx suggest the server routes mostly frame the UI while interaction-heavy logic runs on the client.

7. The admin surface is separate from the user dashboard and is organized under src/app/admin. It includes overview, cards, users, payments, and settings, with shared navigation in AdminNav.tsx and admin-specific UI components in src/components/admin. This is a clear operator console for managing the platform rather than end-user content.

8. Payments are a first-class subsystem built around Razorpay. The integration is isolated in src/lib/razorpay with client, order service, verification, webhook handling, validation, and test coverage. The API routes in src/app/api/payments/razorpay/* handle order creation, verification, and webhook events, while dashboard/admin payment views consume that state.

9. Analytics and operational controls are also exposed as APIs. src/app/api/analytics/view and click capture user interaction, src/app/api/dashboard/stats feeds dashboard metrics, and src/app/api/system/maintenance supports platform maintenance mode. These endpoints suggest a telemetry-and-control plane alongside the product UI.

10. The business logic is concentrated in src/lib: database access (db.ts), shared actions (actions.ts, admin-actions.ts, payment-actions.ts), card mapping (cardMapper.ts), URL helpers, and email delivery (mail.ts). This keeps UI components thin and separates domain logic from route handlers.

11. Persistence is Prisma-based. prisma/schema.prisma, prisma/seed.ts, dev.db, and the Prisma config files indicate a schema-driven database layer with local seeded data for development. The presence of scripts like promote-admin*.ts and promote.sql shows operational tooling for role management.

12. The repo also contains deployment and environment management helpers (set_vercel_envs.js, sync-vercel.js, upload_env.js, docs/RAZORPAY_GO_LIVE.md), which matters because the payment and auth subsystems depend on correctly provisioned environment variables in production.

13. In architecture-diagram terms, the key boundaries are: public marketing vs authenticated app vs admin console; UI routes vs server API routes; core app logic vs Prisma persistence; and the isolated Razorpay integration boundary that connects checkout, verification, and webhook processing.