Create a full-stack web application using Next.js App Router with a multi-page structure. The application will be a Property Payment Tracker designed to help homeowners manage their property tax payments, especially when using an escrow service.
**Technology Stack:**
* **Frontend:** Next.js (App Router)
* **Styling:** Tailwind CSS
* **Database:** PostgreSQL with Drizzle ORM for type-safe database interactions.
* **Authentication:** NextAuth.js for secure user authentication.
* **State Management:** React Context API or Zustand for frontend state.
**Core Functionalities & Features:**
1. **User Authentication:** Implement secure user registration and login using NextAuth.js (e.g., with email/password and OAuth providers like Google).
2. **Property Management:** Users should be able to add, view, edit, and delete multiple properties. Each property should store:
* Property Address (street, city, state, zip code)
* Mortgage Bank Name
* Loan Account Number
* Estimated Annual Property Tax Amount
* Escrow Service Enabled (boolean)
* Property Tax Due Dates (e.g., month/day or specific dates if known).
3. **Escrow Payment Tracking:** For properties with escrow enabled, allow users to input:
* Escrow Payment Amount
* Escrow Payment Date
* Next Expected Escrow Payment Date (if known).
4. **Manual Payment Tracking:** Users should be able to manually record their own property tax payments, including:
* Manual Payment Amount
* Manual Payment Date.
5. **Payment Reconciliation & Alerts:** The core feature is to compare escrow payments and manual payments for the same property and tax period.
* Implement logic to detect potential duplicate payments (if manual payment is made when escrow is expected to pay, or if total payments exceed the annual tax).
* Display clear indicators (e.g., color-coding, status badges) on the property dashboard showing payment status (e.g., 'On Track', 'Potential Duplicate Payment', 'Underpaid', 'Overpaid').
* Generate alerts or notifications for the user when a potential duplicate or issue is detected.
6. **Dashboard:** A main dashboard for logged-in users displaying a summary of all their properties, their current payment status, and upcoming due dates.
7. **Property Detail Page:** A dedicated page for each property showing all its details, payment history (both escrow and manual), and current reconciliation status.
8. **Database Schema (Drizzle):** Define the following tables:
* `users` (id, name, email, image, ...)
* `accounts` (provider, providerAccountId, ...)
* `sessions` (sessionToken, ...)
* `verification_tokens` (...)
* `properties` (id, userId, address, bankName, loanAccountNumber, annualTaxAmount, escrowEnabled, nextEscrowPaymentDate, createdAt, updatedAt)
* `payments` (id, propertyId, userId, type: enum('escrow', 'manual'), amount, date, createdAt, updatedAt)
**Project Structure (Next.js App Router):**
* `app/` directory for routing.
* `app/layout.tsx` (Root layout)
* `app/(auth)/login/page.tsx`, `app/(auth)/register/page.tsx` (Authentication pages)
* `app/dashboard/page.tsx` (Main user dashboard)
* `app/properties/page.tsx` (List of all properties)
* `app/properties/[id]/page.tsx` (Detail page for a single property)
* `app/properties/new/page.tsx` (Form to add a new property)
* `app/api/` for API routes (e.g., for CRUD operations on properties and payments).
* `lib/` for database connection (Drizzle), utility functions, etc.
* `components/` for reusable UI components.
**API Routes (Example):**
* `POST /api/properties`: Create a new property.
* `GET /api/properties`: Get all properties for the logged-in user.
* `GET /api/properties/[id]`: Get details for a specific property.
* `PUT /api/properties/[id]`: Update a property.
* `DELETE /api/properties/[id]`: Delete a property.
* `POST /api/payments`: Create a new payment (manual or escrow).
* `GET /api/properties/[id]/payments`: Get all payments for a property.
**CRUD Implementation:** Ensure full Create, Read, Update, and Delete operations are implemented for properties and payments via the API routes, interacting with the Drizzle ORM and PostgreSQL database. The payment reconciliation logic should be triggered upon creation or update of payments, and potentially when property details (like annual tax amount) are changed.