nishal77/udhaarclear

1. Overall shape

- This is a multi-surface Next.js App Router application: a public marketing site, an authenticated SaaS dashboard, a payment portal, and a server-side API layer.

- The main architectural split is between app/ route groups, reusable feature components in components/, and server/domain code in lib/.

2. Route boundaries

- app/(auth) contains login/signup screens.

- app/(dashboard) contains the main product: customers, invoices, analytics, payments, reports, reminders, team, settings, WhatsApp/email logs, and MSME/legal features.

- app/onboarding and app/pay/[id] are separate flows that sit outside the normal dashboard experience.

- app/api/* is the backend surface for all business operations.

3. Authentication and onboarding flow

- Auth is OTP-based, with routes for login, signup, OTP verification, and callback handling.

- lib/auth/otp-cookie.ts and proxy.ts indicate session/state enforcement at the edge/middleware boundary.

- app/onboarding handles post-auth setup before a user fully enters the dashboard.

4. Core business domain

- The product centers on receivables management: customers, invoices, reminders, payments, and collections.

- Customer and invoice CRUD exist in both pages and API routes, with matching create/edit/detail screens.

- Legal notice and MSME-related pages suggest debt-recovery workflows beyond simple invoicing.

5. Analytics subsystem

- Analytics is a first-class area with dedicated dashboard pages for heatmap, predictive insights, recovery analytics, and digest views.

- These screens are backed by API routes under app/api/analytics/*.

- UI components in components/analytics appear to be reusable visualizations driven by backend-derived collection data.

6. Reminder and notification engine

- Reminders are orchestrated by a server-side service layer in lib/services/reminder-service.ts and lib/cron/reminder-engine.ts.

- app/api/cron/send-reminders suggests scheduled execution, likely via a hosted cron trigger.

- Delivery channels include email and WhatsApp, with tracking endpoints for email open events and log dashboards for message history.

7. Payments and collection confirmation

- Razorpay is the external payment rail, with dedicated client, payment-link, and webhook helpers in lib/razorpay.

- The payment experience has its own public flow under app/pay/[id], plus confirm/verify endpoints for completing and validating payment events.

- Payment status updates likely feed back into invoices, reminders, and analytics.

8. Settings and tenant administration

- The settings area is modular: profile, billing, team, integrations, webhooks, WhatsApp, and payments.

- components/settings/* and app/(dashboard)/settings/* indicate separate server and client responsibilities.

- Team/business pages suggest multi-business or multi-user workspace management rather than a single-user app.

9. Shared dashboard shell

- The authenticated UI is wrapped by shared layout components: sidebar, top bar, page header, mobile nav, notification dropdown, and dashboard shell.

- Most feature pages are thin route wrappers around feature-specific components, keeping page files light and presentation logic centralized.

- Shared primitives in components/ui and components/shared standardize charts, cards, loading states, and empty states.

10. Domain libraries and integrations

- lib/validations defines schema-level input validation for customers, invoices, and shared structures.

- lib/utils contains common formatting and domain helpers such as currency, date, phone, GST, and API error handling.

- Email, WhatsApp, PDF generation, and Razorpay clients are isolated in lib/email, lib/whatsapp, lib/pdf, and lib/razorpay, keeping external integrations out of page code.

11. Persistence and data contracts

- Prisma is the primary database layer, with schema and migrations under prisma/.

- lib/prisma/client.ts is the main database access point, while types/database.ts and other type files provide typed contracts for external payloads.

- The architecture suggests server routes and services read/write the database, then drive UI state through pages and dashboards.

12. Testing and verification

- Vitest-based tests cover utility and domain logic such as currency formatting, validations, and tone engine behavior.

- This indicates the repo is not only UI-heavy; it also has testable backend/domain rules around reminders, messaging tone, and validation.

Overall, the diagram should show a Next.js front end composed of several route groups, a server API layer for CRUD/integrations/analytics, a shared domain/service layer in lib/, and external dependencies for auth/session, database, payments, email, WhatsApp, and scheduled reminder delivery.