System Requirements Document for vinod-photography-manager

1. Introduction

Vinod Photography Manager is a complete, professional, mobile-friendly wedding photography business management application for Vinod Photography, an Indian wedding photography business. It is a real, functional application — not a static design, mockup, or demo — with persistent database storage, secure authentication, working forms, editing, deletion, search, reports, and backups. All data must remain saved after refreshing, logging out, or reopening the app.

The product runs on a proper database and backend, uses Indian Rupees (INR ₹), Indian date formats, and the Asia/Kolkata timezone, and presents a premium black, ivory, and gold visual theme. It is designed to be easy to use on iPhone, Android, tablets, and desktop.

The audience is the operator of a small premium Indian wedding photography studio: booking-led, deadline-heavy, money-sensitive, and selling an aspirational, once-in-a-lifetime product. The operator works from a phone at a venue late at night and from a laptop doing month-end reports, so the app must feel like a luxury studio's back office — confident, editorial, quietly expensive — while remaining fast and data-dense.

The application must deliver the actual working application, provide setup instructions, database configuration, and deployment instructions, and clearly identify any features that remain incomplete.

2. System Overview

Vinod Photography Manager is delivered as a responsive web application / progressive web app (PWA) backed by a persistent server-side database. The provisioned infrastructure is:

• backend — a shared FastAPI process hosting all application APIs and domain modules.
• database — MariaDB holding all application-owned persistent data.
• frontend — a React application UI.

The application is single-tenant to Vinod Photography and its private business records. Access to all business data requires secure login; the public entry and sign-in surfaces are the only anonymously reachable pages.

Actors. The active human personas are the Business Owner / Studio Manager, the Team Member / Freelancer, and the Editor / Delivery Coordinator. External notification providers (push/email) are non-persona actors owned outside the application and are only active once properly configured with credentials.

Accepted behavior. The application covers: a dashboard of business totals with add shortcuts; customer and booking management with unique booking IDs and multiple functions per booking; a function and event scheduler with calendar, chronological agenda, 7-day highlights, preparation/ordering deadlines, and attendance tracking; a reusable team member directory with double-booking prevention and conflict warnings; staff assignments and payments with allowances, partial payments, dues, and filterable history; customer payment management with installments, overdue alerts, receipts, and a ledger that never double-counts; business expenses and profit with a clearly labeled calculation method and monthly/yearly reports; photo, video, and album delivery workflow tracking with progress and overdue alerts; in-app reminders with optional, permission-gated push/email notifications; global search, filters, CSV/PDF exports, and full backup/restore; a polished responsive UI with desktop sidebar and mobile navigation; and security, reliability, and data-integrity controls.

Ownership. All business workflows are owned by first-party application pages. Push and email notifications are owned by external providers and are only claimed active when properly configured. Background computation (totals, balances, progress, alerts) is a system process supporting the human-facing pages.

Narrow exclusions. The application does not present itself as a static design or demo; it does not claim notifications are active unless properly configured; it does not pretend external-credential features already work; and it does not count any payment twice.

Removed from scope

• None.

2a. Product Interpretation and Delivery Boundary

Vinod Photography Manager is a private, single-studio back office. The public entry surface explains the product and who it is for; the sign-in surface establishes and verifies the studio owner's identity; every other destination is protected and requires login. Business records are private to the authenticated studio operator.

The application owns its identity and persistent data: the studio owner self-enrolls on first use and verifies on return, and all records persist across refresh, logout, and reopening. There is no differentiated permission model beyond authenticated access to the studio's own private records; the Team Member / Freelancer and Editor / Delivery Coordinator personas are maintained and tracked within the studio's records rather than given separate account-based visibility.

Current delivery covers all fourteen feature areas in the requirement thread. External notification delivery (push/email) is a current capability only where supported and properly configured with credentials; until then the app provides in-app reminders and does not claim external notifications are active. Where a feature requires external credentials, the application explains how to configure them rather than pretending they already work, and any features that remain incomplete are clearly identified.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry explaining Vinod Photography Manager, who it is for (Vinod Photography, an Indian wedding photography business), and what it does before sign-in. Editorial masthead treatment with the studio wordmark and a concise statement of the product's purpose.
• Primary action: Proceed to sign-in / enrollment.
• Supporting actions: Navigate to Login.
• Domain entities: None (no business data exposed).
• Component responsibilities: Masthead wordmark; product-purpose copy; entry CTA to Login.
• States: Loading (static content, no data fetch); empty/success not applicable; error not applicable; recovery — if the app cannot reach the backend, the entry remains readable and the CTA surfaces a connection message.

Login

• Information/state: Secure sign-in protecting private business records. Supports self-service enrollment for first use and returning verification.
• Primary action: Sign in with credentials.
• Supporting actions: Self-service enrollment on first use; recover from invalid credentials.
• Domain entities: Studio owner identity/credentials.
• Component responsibilities: Credential form with input validation; enrollment path; error messaging; redirect to Dashboard on success.
• States: Loading (submitting); empty (blank form); success (redirect to Dashboard); error (invalid credentials, validation failure); recovery (retry, re-enter credentials).

Dashboard

• Information/state: Total bookings, upcoming functions, total package value, customer payments received, outstanding customer balances, total business expenses, staff payments due, pending album/video deliveries, and estimated profit. Masthead band of large KPI numerals; agenda/upcoming functions and money/delivery panels.
• Primary action: Review business totals.
• Supporting actions: Shortcuts to add bookings, functions, team members, payments, and expenses; prominent Add Booking button.
• Domain entities: Bookings, functions, customer payments, staff payments, expenses, delivery tasks.
• Component responsibilities: KPI numerals with count-up on load; agenda list; money and delivery summary panels; add shortcuts.
• States: Loading (fetching totals); empty (helpful empty states when no records); success (totals rendered); error (totals unavailable, retry); recovery (retry fetch).

Bookings

• Information/state: List and detail of customer bookings storing couple names, phone numbers, optional email, event dates, booking date, address, venue, Google Maps link, package name, package price, services included, special instructions, and booking status; unique booking ID per booking; multiple functions per booking.
• Primary action: Create a booking.
• Supporting actions: View, edit, search, archive; add functions under a booking; assign team members to the booking.
• Domain entities: Booking, customer/couple, function, team assignment.
• Component responsibilities: Booking list with search; booking form with validation; unique booking ID generation; archive control with confirmation; ledger-row expansion for detail.
• States: Loading; empty (helpful empty state with Add Booking); success; error (validation/save failure, retry); recovery (edit and resubmit).

Calendar & Functions

• Information/state: Functions per booking (engagement, pre-wedding, Haldi, Mehendi, wedding, reception, family function, custom events), each with date, start time, venue, Google Maps location, assigned team members, equipment checklist, preparation notes, items to order, order-by date, and completion status. Calendar and chronological agenda; events in the next 7 days and preparation/ordering deadlines highlighted; attendance and role performed per function.
• Primary action: Add/schedule a function.
• Supporting actions: Assign team members; record attendance and role; edit function details; mark completion status.
• Domain entities: Function, team assignment, attendance record, equipment checklist, order items.
• Component responsibilities: Calendar view; chronological agenda; 7-day and deadline highlighting; assignment and attendance controls; conflict warning on assignment.
• States: Loading; empty (no functions scheduled); success; error (conflict warning, validation failure); recovery (adjust assignment, retry).

Team

• Information/state: Reusable directory of photographers, cinematographers, traditional photographers, traditional videographers, drone operators, photo editors, video editors, assistants, and other freelancers, storing full name, phone number, role, usual rate, payment details, and notes.
• Primary action: Add a team member.
• Supporting actions: Edit, search, assign to bookings and individual functions; view conflict warnings.
• Domain entities: Team member, role, assignment.
• Component responsibilities: Directory list with search; member form; assignment controls; double-booking conflict warning.
• States: Loading; empty (no team members); success; error (validation/conflict); recovery (resolve conflict, retry).

Customer Payments

• Information/state: Per-wedding package price, booking advance, pre-wedding payment, wedding-day payment, other installments, and final delivery payment; multiple partial payments with date, amount, method, and notes; automatic total received and remaining balance; customized installment schedules; overdue payment alerts; receipts; customer ledger.
• Primary action: Record a customer payment.
• Supporting actions: Define installment schedule; view ledger and receipts; filter; resolve overdue alerts.
• Domain entities: Customer payment, installment schedule, receipt, ledger.
• Component responsibilities: Payment entry form; balance calculation; duplicate-payment prevention; installment schedule editor; receipt generation; ledger view.
• States: Loading; empty (no payments recorded); success; error (duplicate payment blocked, validation failure); recovery (correct entry, retry).

Staff Payments

• Information/state: Per-function assignment records with team member, role, agreed fee, travel allowance, food/accommodation allowance, total payable, amount paid, payment date, payment method, and remaining balance; partial and multiple payments; total earnings and outstanding dues per staff member; payment history filterable by person, wedding, function, and date.
• Primary action: Record a staff payment.
• Supporting actions: Record partial payments; view dues and earnings; filter history.
• Domain entities: Staff assignment, staff payment, allowance, dues.
• Component responsibilities: Assignment/payment form; balance calculation; dues summary; filterable history.
• States: Loading; empty (no assignments/payments); success; error (validation failure); recovery (correct entry, retry).

Expenses

• Information/state: Expenses for travel, fuel, accommodation, meals, equipment rental, album printing, staff fees, editing, outsourcing, and miscellaneous; each linked to a specific wedding or marked general; vendor, amount, date, payment status, and receipt attachment.
• Primary action: Record an expense.
• Supporting actions: Link to wedding or mark general; attach receipt; edit; filter.
• Domain entities: Expense, vendor, receipt attachment, wedding link.
• Component responsibilities: Expense form; wedding/general toggle; receipt upload; expense list.
• States: Loading; empty (no expenses); success; error (validation/upload failure); recovery (retry).

Deliveries

• Information/state: Delivery workflow per wedding covering photo backup, photo selection, photo editing, video editing, teaser, full-length video, album design, customer approval, album sheet count, extra sheets, printing, quality check, and final delivery; each task with status, responsible editor, due date, notes, and completion date; custom tasks; automatic progress; overdue and delivery-deadline alerts.
• Primary action: Update a delivery task.
• Supporting actions: Add custom tasks; assign responsible editor; set due dates; mark completion; act on overdue alerts.
• Domain entities: Delivery task, editor assignment, album sheet count, progress.
• Component responsibilities: Workflow task list; status controls; progress calculation; overdue/deadline alerts.
• States: Loading; empty (no delivery tasks); success; error (validation failure); recovery (retry).

Reports

• Information/state: Estimated profit per wedding (customer revenue actually received or contract revenue, with clearly labeled calculation method, minus relevant expenses); business revenue, expenses, receivables, payables, and estimated profit in monthly and yearly reports; global search across customer names, phone numbers, booking IDs, staff members, venues, and functions; filters by date, payment status, delivery status, and staff member; exports of customer ledgers, staff payment reports, expense reports, wedding schedules, and delivery reports to CSV or PDF.
• Primary action: Generate/view a report.
• Supporting actions: Global search; apply filters; export to CSV or PDF.
• Domain entities: Report, export, search index across bookings/team/functions.
• Component responsibilities: Report views; labeled profit calculation method; search and filter controls; CSV/PDF export.
• States: Loading; empty (no matching results); success; error (export failure); recovery (retry).

Settings

• Information/state: Reminder configuration (including one day before a function); push/email notification configuration with user permission and clear indication of whether notifications are active; full data backup and restore.
• Primary action: Configure reminders and notifications.
• Supporting actions: Run backup; restore from backup; configure external credentials.
• Domain entities: Reminder settings, notification configuration, backup.
• Component responsibilities: Reminder settings form; notification status indicator (active only when properly configured); backup/restore controls with confirmation.
• States: Loading; empty (defaults); success (saved/backup complete); error (restore failure, unconfigured notifications); recovery (retry, reconfigure).

3. Functional Requirements

FR-1 — Product identity and locale. As the Business Owner / Studio Manager I should use an application named "Vinod Photography Manager" serving Vinod Photography, an Indian wedding photography business, using INR (₹), Indian date formats, and the Asia/Kolkata timezone. (explicit)

• Trigger/input: Any screen displaying money, dates, or times.
• Observable result: Amounts render in ₹, dates in Indian format, times in Asia/Kolkata.
• Access: Login required for business data.
• Failure/recovery: None material.
• Continuation: Applies across all pages.

FR-2 — Real, persistent, mobile-friendly application. As the Business Owner / Studio Manager I should use a real, functional, mobile-friendly application on iPhone, Android, tablets, and desktop with persistent database storage, secure authentication, working forms, editing, deletion, search, reports, and backups, where data survives refresh, logout, and reopening. (explicit)

• Trigger/input: Any create/edit/delete/search/report/backup action.
• Observable result: Records persist across refresh, logout, and reopening.
• Access: Login required.
• Failure/recovery: Save failures surface an error and allow retry.
• Continuation: Data remains available on return.

FR-3 — Dashboard totals and shortcuts. As the Business Owner / Studio Manager I should see total bookings, upcoming functions, total package value, customer payments received, outstanding customer balances, total business expenses, staff payments due, pending album/video deliveries, and estimated profit, with shortcuts to add bookings, functions, team members, payments, and expenses. (explicit)

• Trigger/input: Opening Dashboard.
• Observable result: All listed totals render; shortcuts open the corresponding add flows.
• Access: Login required.
• Failure/recovery: Totals unavailable → error with retry.
• Continuation: Shortcuts lead to add flows.

FR-4 — Booking CRUD and fields. As the Business Owner / Studio Manager I should create, view, edit, search, and archive customer bookings storing couple names, phone numbers, optional email, event dates, booking date, address, venue, Google Maps link, package name, package price, services included, special instructions, and booking status, with a unique booking ID per booking. (explicit)

• Trigger/input: Booking form submission.
• Observable result: Booking saved with unique booking ID; searchable; archivable.
• Access: Login required.
• Failure/recovery: Validation failure → inline errors, retry.
• Continuation: Booking available for functions and payments.

FR-5 — Multiple functions per booking. As the Business Owner / Studio Manager I should add multiple functions (engagement, pre-wedding, Haldi, Mehendi, wedding, reception, family function, custom events) under one wedding booking, each with its own date, start time, venue, Google Maps location, assigned team members, equipment checklist, preparation notes, items to order, order-by date, and completion status. (explicit)

• Trigger/input: Adding a function to a booking.
• Observable result: Function saved with all listed fields.
• Access: Login required.
• Failure/recovery: Validation failure → retry.
• Continuation: Function appears in calendar and agenda.

FR-6 — Calendar, agenda, highlights, attendance. As the Business Owner / Studio Manager I should see a calendar and chronological agenda, have events in the next 7 days and preparation/ordering deadlines highlighted, and track who attended each function and what role they performed. (explicit)

• Trigger/input: Viewing Calendar & Functions; recording attendance.
• Observable result: Calendar/agenda render; 7-day and deadline highlights shown; attendance and role recorded.
• Access: Login required.
• Failure/recovery: Save failure → retry.
• Continuation: Attendance persists per function.

FR-7 — Team directory. As the Business Owner / Studio Manager I should maintain a reusable directory of photographers, cinematographers, traditional photographers, traditional videographers, drone operators, photo editors, video editors, assistants, and other freelancers, storing full name, phone number, role, usual rate, payment details, and notes, and assign them to bookings and individual functions. (explicit)

• Trigger/input: Adding/editing a team member; assigning to booking/function.
• Observable result: Member saved; assignment recorded.
• Access: Login required.
• Failure/recovery: Validation failure → retry.
• Continuation: Member reusable across bookings.

FR-8 — Double-booking prevention. As the Business Owner / Studio Manager I should be prevented from accidentally double-booking a team member for overlapping events and be warned about conflicts. (explicit)

• Trigger/input: Assigning a member to an overlapping event.
• Observable result: Conflict warning shown; overlapping assignment blocked.
• Access: Login required.
• Failure/recovery: User adjusts assignment and retries.
• Continuation: Non-conflicting assignment proceeds.

FR-9 — Staff assignment and payment fields. As the Business Owner / Studio Manager I should record, for every function, each assigned team member, role, agreed fee, travel allowance, food/accommodation allowance, total payable, amount paid, payment date, payment method, and remaining balance, supporting partial and multiple payments. (explicit)

• Trigger/input: Recording a staff payment.
• Observable result: Payment saved; balance recalculated.
• Access: Login required.
• Failure/recovery: Validation failure → retry.
• Continuation: Multiple payments accumulate.

FR-10 — Staff earnings, dues, history. As the Business Owner / Studio Manager I should see total earnings and outstanding dues per staff member and a payment history filterable by person, wedding, function, and date. (explicit)

• Trigger/input: Viewing Staff Payments; applying filters.
• Observable result: Earnings/dues shown; history filtered.
• Access: Login required.
• Failure/recovery: No matches → empty state.
• Continuation: Filters adjustable.

FR-11 — Customer payment tracking. As the Business Owner / Studio Manager I should track each wedding's package price, booking advance, pre-wedding payment, wedding-day payment, other installments, and final delivery payment, record multiple partial payments with date, amount, method, and notes, and have total received and remaining balance calculated automatically, with customized installment schedules, overdue payment alerts, receipts, and a customer ledger, never counting a payment twice. (explicit)

• Trigger/input: Recording a payment; defining a schedule.
• Observable result: Payment saved once; totals/balance updated; receipt and ledger available; overdue alerts shown.
• Access: Login required.
• Failure/recovery: Duplicate payment blocked; validation failure → retry.
• Continuation: Ledger reflects all payments.

FR-12 — Expenses. As the Business Owner / Studio Manager I should record travel, fuel, accommodation, meals, equipment rental, album printing, staff fees, editing, outsourcing, and miscellaneous expenses, each linked to a specific wedding or marked as general business expense, tracking vendor, amount, date, payment status, and receipt attachment. (explicit)

• Trigger/input: Recording an expense.
• Observable result: Expense saved with wedding/general link and receipt.
• Access: Login required.
• Failure/recovery: Validation/upload failure → retry.
• Continuation: Expense included in reports.

FR-13 — Profit and financial reports. As the Business Owner / Studio Manager I should see estimated profit per wedding calculated as customer revenue actually received or contract revenue, with a clearly labeled calculation method, minus relevant expenses, and see business revenue, expenses, receivables, payables, and estimated profit in monthly and yearly reports. (explicit)

• Trigger/input: Viewing Reports.
• Observable result: Labeled profit calculation and monthly/yearly figures render.
• Access: Login required.
• Failure/recovery: No data → empty state.
• Continuation: Reports refresh with new data.

FR-14 — Delivery workflow. As the Editor / Delivery Coordinator I should track the workflow for every wedding — photo backup, photo selection, photo editing, video editing, teaser, full-length video, album design, customer approval, album sheet count, extra sheets, printing, quality check, and final delivery — with each task having a status, responsible editor, due date, notes, and completion date, supporting custom tasks, automatic progress calculation, and alerts for overdue work and delivery deadlines. (explicit)

• Trigger/input: Updating a task status/completion.
• Observable result: Task saved; progress recalculated; overdue/deadline alerts shown.
• Access: Login required.
• Failure/recovery: Validation failure → retry.
• Continuation: Progress reflects completion.

FR-15 — Reminders and notifications. As the Business Owner / Studio Manager I should receive in-app reminders for upcoming functions, preparation deadlines, items to order, customer installments, staff payments, and delivery dates; where supported, integrate push or email notifications with user permission; configure reminders including one day before a function; and the app must not claim notifications are active unless properly configured. (explicit)

• Trigger/input: Configuring reminders; enabling notifications.
• Observable result: In-app reminders shown; external notifications active only when properly configured; status truthfully indicated.
• Access: Login required.
• Failure/recovery: Unconfigured → app states notifications are not active.
• Continuation: Settings persist.

FR-16 — Global search and filters. As the Business Owner / Studio Manager I should search globally across customer names, phone numbers, booking IDs, staff members, venues, and functions, and filter by date, payment status, delivery status, and staff member. (explicit)

• Trigger/input: Search query or filter selection.
• Observable result: Matching results shown.
• Access: Login required.
• Failure/recovery: No matches → empty state.
• Continuation: Query/filters adjustable.

FR-17 — Exports and backup/restore. As the Business Owner / Studio Manager I should export customer ledgers, staff payment reports, expense reports, wedding schedules, and delivery reports to CSV or PDF, and perform a full data backup and restore. (explicit)

• Trigger/input: Selecting export or backup/restore.
• Observable result: File generated; backup created; restore applied.
• Access: Login required.
• Failure/recovery: Export/restore failure → error with retry.
• Continuation: Data intact after restore.

FR-18 — Premium responsive UI. As the Business Owner / Studio Manager I should use a polished, premium, responsive dashboard with a left sidebar on desktop and bottom navigation or a mobile menu on phones, readable typography, black and gold accents, clear status indicators, confirmation dialogs before deleting records, helpful empty states, and a prominent Add Booking button. (explicit)

• Trigger/input: Any navigation or delete action.
• Observable result: Responsive layout; delete requires confirmation; empty states shown.
• Access: Login required.
• Failure/recovery: N/A.
• Continuation: Navigation across sections.

FR-19 — Main sections. As the Business Owner / Studio Manager I should navigate the main sections Dashboard, Bookings, Calendar & Functions, Team, Customer Payments, Staff Payments, Expenses, Deliveries, Reports, and Settings. (explicit)

• Trigger/input: Selecting a section.
• Observable result: Section opens.
• Access: Login required.
• Failure/recovery: N/A.
• Continuation: Return to any section.

FR-20 — Security and reliability. As the Business Owner / Studio Manager I should have secure login, database access controls, input validation, and reliable backups, with business records kept private, proper database relationships between customers, bookings, functions, staff, assignments, payments, expenses, and delivery tasks, prevention of duplicate payment entries, and preserved transaction history. (explicit)

• Trigger/input: Any data operation.
• Observable result: Access controlled; inputs validated; duplicates blocked; history preserved.
• Access: Login required.
• Failure/recovery: Invalid input rejected; retry.
• Continuation: Records remain consistent.

FR-21 — Production-ready stack and CRUD. As the Business Owner / Studio Manager I should have a production-ready stack (responsive web app/PWA with persistent backend), required database tables and relationships, configured authentication and permissions, and all CRUD operations implemented. (explicit)

• Trigger/input: Any CRUD operation.
• Observable result: Operations succeed against persistent backend.
• Access: Login required.
• Failure/recovery: Errors surfaced with retry.
• Continuation: Data persists.

FR-22 — External credential honesty. As the Business Owner / Studio Manager I should be told how to configure external credentials where a feature requires them, rather than the app pretending they already work. (explicit)

• Trigger/input: Viewing a credential-dependent feature.
• Observable result: Configuration guidance shown; feature marked inactive until configured.
• Access: Login required.
• Failure/recovery: Unconfigured → inactive state.
• Continuation: Configure and retry.

FR-23 — Setup, deployment, and incompleteness disclosure. As the Business Owner / Studio Manager I should receive setup instructions, database configuration, and deployment instructions, and have any features that remain incomplete clearly identified. (explicit)

• Trigger/input: Reading delivered documentation.
• Observable result: Instructions and incompleteness list provided.
• Access: N/A.
• Failure/recovery: N/A.
• Continuation: N/A.

FR-24 — Self-service enrollment and returning verification. As the Business Owner / Studio Manager I should establish my identity on first use and verify it on return via secure login before accessing private records. (required_inference)

• Trigger/input: First visit (enrollment) or return visit (sign-in).
• Observable result: Authenticated session; access to protected pages.
• Access: Anonymous entry on Landing/Login; protected pages require login.
• Failure/recovery: Invalid credentials → error, retry.
• Continuation: Redirect to Dashboard.

FR-25 — Persistent backend with authentication and access controls. As the Business Owner / Studio Manager I should have my records stored in a persistent backend database with authentication and access controls so they survive refresh, logout, and reopening. (required_inference)

• Trigger/input: Any save operation.
• Observable result: Data persisted and access-controlled.
• Access: Login required.
• Failure/recovery: Save failure → retry.
• Continuation: Data available on return.

FR-26 — Notification credentials before claiming active. As the Business Owner / Studio Manager I should only see push/email notifications claimed active after external notification credentials are configured. (required_inference)

• Trigger/input: Enabling notifications.
• Observable result: Status reflects configuration truthfully.
• Access: Login required.
• Failure/recovery: Unconfigured → inactive state with guidance.
• Continuation: Configure and retry.

4. User Personas

Business Owner / Studio Manager

• Product context: Runs Vinod Photography end to end — the booking-led, deadline-heavy, money-sensitive operator of a small premium Indian wedding photography studio. Works from a phone at a venue late at night and from a laptop doing month-end reports.
• Primary goal: Accurate outstanding balances, dues, and estimated profit, with all records persisting across sessions.
• Distinct responsibilities: Creates and archives wedding bookings; schedules functions; assigns team members; records customer and staff payments and expenses; monitors delivery progress; reviews dashboard totals, reports, and backups; configures reminders and notifications.
• Inputs/decisions: Booking details, package prices, payment amounts and methods, expense entries, installment schedules, reminder configuration, backup/restore decisions.
• Interactions: Assigns Team Members / Freelancers to functions; relies on Editors / Delivery Coordinators to update delivery tasks; configures external notification providers.
• Observable success: Dashboard totals and reports reconcile; balances and dues are correct; data survives refresh, logout, and reopening.

Team Member / Freelancer

• Product context: Photographers, cinematographers, traditional photographers and videographers, drone operators, editors, assistants, and other freelancers maintained in the reusable directory and assigned to bookings and individual functions.
• Primary goal: Be correctly assigned, tracked for attendance and role, and paid correctly with accurate earnings and outstanding dues.
• Distinct responsibilities: Appears in the directory with role, usual rate, payment details, and notes; is assigned to functions; attendance and role performed are recorded; earnings, partial payments, and dues are tracked per function.
• Inputs/decisions: Availability implied by assignment; role performed at a function.
• Interactions: Assigned by the Business Owner / Studio Manager; payment history recorded on their behalf.
• Observable success: Their earnings and outstanding dues are accurately reflected and their payment history is filterable.

Editor / Delivery Coordinator

• Product context: Owns the post-production workflow for each wedding — photo backup, selection, photo and video editing, teaser, full-length video, album design, customer approval, printing, quality check, and final delivery.
• Primary goal: Keep delivery tasks on schedule and progress accurate.
• Distinct responsibilities: Updates task status, due dates, notes, and completion dates; adds custom tasks; acts on overdue-work and delivery-deadline alerts.
• Inputs/decisions: Task status changes, completion dates, album sheet counts and extra sheets.
• Interactions: Works within Deliveries; progress feeds the Dashboard's pending deliveries and Reports.
• Observable success: Delivery progress calculates automatically and overdue work is surfaced.

5. Core User Flows

Flow A — First use and returning sign-in (Business Owner / Studio Manager)

1. Owner opens the app at Landing (anonymous) and reads what Vinod Photography Manager does.
2. Owner proceeds to Login and self-enrolls on first use.
3. On return, owner signs in at Login; invalid credentials show an error and allow retry.
4. On success, owner lands on Dashboard; records persist across refresh, logout, and reopening.

Flow B — Create a wedding booking (Business Owner / Studio Manager)

1. Owner opens Bookings (or uses the prominent Add Booking button / Dashboard shortcut).
2. Owner enters couple names, phone numbers, optional email, event dates, booking date, address, venue, Google Maps link, package name, package price, services included, special instructions, and booking status.
3. On save, a unique booking ID is generated and the booking appears in the list.
4. Validation failures show inline errors; owner corrects and resubmits.
5. Owner can view, edit, search, and archive the booking (archive requires confirmation).

Flow C — Add multiple functions and schedule (Business Owner / Studio Manager)

1. Owner opens a booking and adds functions (engagement, pre-wedding, Haldi, Mehendi, wedding, reception, family function, custom).
2. For each function, owner sets date, start time, venue, Google Maps location, equipment checklist, preparation notes, items to order, order-by date, and completion status.
3. Functions appear in Calendar & Functions calendar and chronological agenda; events in the next 7 days and preparation/ordering deadlines are highlighted.
4. After the event, owner records who attended and what role they performed.

Flow D — Assign team and prevent double-booking (Business Owner / Studio Manager)

1. Owner maintains the Team directory (full name, phone, role, usual rate, payment details, notes).
2. Owner assigns members to bookings and individual functions.
3. If an assignment overlaps an existing event for that member, a conflict warning appears and the overlapping assignment is blocked; owner adjusts and retries.
4. Non-conflicting assignments proceed and appear on the function.

Flow E — Record customer payments and ledger (Business Owner / Studio Manager)

1. Owner opens Customer Payments for a wedding and records the booking advance, pre-wedding payment, wedding-day payment, other installments, and final delivery payment as multiple partial payments with date, amount, method, and notes.
2. The app calculates total received and remaining balance automatically and never counts a payment twice; duplicate entries are blocked.
3. Owner defines a customized installment schedule; overdue payment alerts surface.
4. Owner views the customer ledger and generates receipts.

Flow F — Record staff fees and partial payments (Business Owner / Studio Manager)

1. Owner opens Staff Payments for a function and records each assigned member's role, agreed fee, travel allowance, food/accommodation allowance, total payable, amount paid, payment date, payment method, and remaining balance.
2. Owner records partial and multiple payments; balances recalculate.
3. Owner views total earnings and outstanding dues per staff member and filters history by person, wedding, function, and date.

Flow G — Record expenses and review profit (Business Owner / Studio Manager)

1. Owner opens Expenses and records travel, fuel, accommodation, meals, equipment rental, album printing, staff fees, editing, outsourcing, or miscellaneous expenses, linking each to a wedding or marking it general, with vendor, amount, date, payment status, and receipt attachment.
2. Owner opens Reports to see estimated profit per wedding (labeled calculation method: revenue actually received or contract revenue minus relevant expenses) and monthly/yearly revenue, expenses, receivables, payables, and estimated profit.

Flow H — Track delivery workflow (Editor / Delivery Coordinator)

1. Coordinator opens Deliveries for a wedding and works through photo backup, selection, photo editing, video editing, teaser, full-length video, album design, customer approval, album sheet count, extra sheets, printing, quality check, and final delivery.
2. For each task, coordinator sets status, responsible editor, due date, notes, and completion date; custom tasks can be added.
3. Progress calculates automatically; overdue work and delivery deadlines raise alerts.
4. Completed tasks feed the Dashboard's pending deliveries and Reports.

Flow I — Reminders and notifications (Business Owner / Studio Manager)

1. Owner opens Settings and configures reminders, including one day before a function.
2. In-app reminders surface for upcoming functions, preparation deadlines, items to order, customer installments, staff payments, and delivery dates.
3. Where supported, owner enables push/email notifications with permission; the app shows them active only when properly configured and otherwise states they are not active.

Flow J — Search, export, and backup (Business Owner / Studio Manager)

1. Owner uses global search across customer names, phone numbers, booking IDs, staff members, venues, and functions, and filters by date, payment status, delivery status, and staff member.
2. Owner exports customer ledgers, staff payment reports, expense reports, wedding schedules, and delivery reports to CSV or PDF.
3. Owner performs a full data backup and restore from Settings; restore failures surface an error and allow retry.

6. Visuals Colors and Theme

Muse: Tobias van Schneider. Headline: "Editorial swagger in black, ivory and gold — a wedding ledger that reads like a fashion masthead."

Mode: Dark mode default (light ivory variant only for printable receipts and exported ledgers).

Colour tokens (dark mode):

• Background: #0E0D0B (near-black ink ground, ~60% of surface)
• Surface: #191713 (warm charcoal cards)
• Hairline: #2A2620 (1px borders)
• Text: #F4EEE2 (ivory — only body text colour; never below 16px on dark ground)
• Primary / Accent: #C9A227 (antique gold — primary CTA, active nav, focus rings, large KPI numerals; never body text or background wash)
• Muted: #9A9184 (taupe — labels, metadata, secondary rows)
• Status: paid/complete in gold #C9A227; due/overdue in burnt vermilion #D4552F; archived in muted taupe #9A9184. Never bootstrap green/blue.

Light variant (print/export only): ground #F4EEE2, text #0E0D0B, same gold accent #C9A227.

Typography:

• Headings: Playfair Display, 700–900, tight leading 0.92–1.0, tracking -0.02em; occasional italic Playfair for accents like "Advance received".
• Body: Archivo.
• KPI numerals: Archivo 700, tabular figures, wide tracking for currency.
• Micro-labels (SECTION, STATUS, DUE): Archivo 600 uppercase 11–12px, +0.14em tracking.
• Scale (1.4 modular): display 56px mobile → 128px desktop (clamp); h1 32→56; h2 24→34; h3 19→22; body 16/17; label 11–12 uppercase. Dashboard KPI numerals 40px mobile → 88px desktop. Line-height 1.55 body, 1.0 display.

Shape language: Sharp corners (0–2px radius max on inputs and chips; buttons hard-edged rectangles). Thin 1px hairline rules as section dividers, full-width rules under page titles, a 2px gold rule as the only decorative line. No soft shadows — depth from a single offset hairline or flat tonal step. Tables/ledgers use ruled rows with 14–18px vertical padding.

Layout: Asymmetric editorial 12-column grid on desktop with fixed 248px left sidebar (black, gold active marker as 3px left bar); content starts at column 2 with wide left margin. Page headers: full-width oversized Playfair title with primary action and hairline beneath. Dashboard: masthead band of 3–4 huge KPI numerals, then two-thirds/one-third split (agenda/upcoming left, money/delivery right). Mobile: bottom nav with five icons plus floating gold "Add booking" pill; tables become stacked ruled cards. Forms single-column, labels above fields, grouped into ruled fieldset bands.

Imagery: No stock wedding photography in chrome — the product's own data is the imagery. Monochrome duotone thumbnails (black/ivory with gold wash) for user-uploaded booking covers, cropped hard to 4:5 or 16:9 and bled to card edge. Playfair-set pull quotes of the couple's special instructions in italic. Receipts and PDF exports use the same black masthead with gold rule and Vinod Photography wordmark.

7. Signature Design Concept

The public entry and the dashboard share one implementable idea: the masthead. On the Landing page, a full-bleed near-black band carries the oversized Playfair wordmark "Vinod Photography" at clamp(44px, 9vw, 128px) flush left, with "Manager" set small in gold uppercase on the baseline, a single full-width 2px gold rule beneath, and a concise statement of who the product is for and what it does, with a hard-edged gold entry CTA to Login. On the Dashboard, the same masthead becomes the product's identity: the wordmark bleeds slightly past the left margin over a horizontal strip of four enormous Archivo KPI numerals — Total package value, Received, Outstanding, Estimated profit — separated by vertical hairlines, with the solid gold "Add booking" rectangle pinned at the far right. The next band is the chronological agenda as ruled editorial rows. No centred text, no illustration, no gradient. This recomposes only accepted content and controls.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: The oversized Playfair wordmark "Vinod Photography" with "Manager" in gold, over the gold rule and entry CTA — type as the hero, no imagery.
• Input → transformation → outcome thesis: On load, the wordmark and the gold rule fade-and-rise once (240ms, cubic-bezier(0.2,0.7,0.2,1)); the entry CTA settles into place. No further motion.
• Motion vocabulary: One slow fade-and-rise on page entry for the title and KPI numerals only; hover swaps on booking rows reveal the ledger summary in place; numbers count up once on dashboard load (600ms) and never again; no bouncing, no parallax, no gradient drift.
• Composed first frame: Near-black band, flush-left wordmark bleeding slightly past the left margin, gold "Manager" on baseline, 2px gold rule, hard-edged gold CTA.
• Reduced-motion state: Final states render instantly; no count-up, no fade.

9. Non-Functional Requirements

• Persistence: All data must remain saved after refreshing, logging out, or reopening the app; the app must not be only a static design or demo. (explicit)
• Backend/database: Use a proper database and backend with persistent storage. (explicit)
• Locale: Use INR (₹), Indian date formats, and Asia/Kolkata timezone. (explicit)
• Privacy and access: Business records must remain private, with secure login, database access controls, and input validation. (explicit)
• Payment integrity: Never count a payment twice; prevent duplicate payment entries and preserve a proper transaction history. (explicit)
• Notification honesty: Do not claim notifications are active unless properly configured; if a feature requires external credentials, explain how to configure them rather than pretending they already work. (explicit)
• Incompleteness disclosure: Clearly identify any features that remain incomplete. (explicit)
• Real delivery: Deliver the actual working application, not merely a plan, mockup, or screenshot. (explicit)
• Responsiveness: Easy to use on iPhone, Android, tablets, and desktop. (explicit)
• Readability: Readable typography; ivory body text never below 16px on the dark ground; readable text and controls stay whole at 375px, 768px, and 1280px. (explicit + direction)
• Accessibility/motion: Respect prefers-reduced-motion by rendering final states instantly. (direction)

10. Tech Stack

• Frontend: React application UI (responsive web app / PWA).
• Backend: Shared FastAPI process hosting all application APIs and domain modules.
• Database: MariaDB for application-owned persistent data, with proper relationships between customers, bookings, functions, staff, assignments, payments, expenses, and delivery tasks.
• Authentication: Secure login with self-service enrollment and returning verification; database access controls and input validation.
• External notifications: Push/email providers configured with credentials; inactive until properly configured.
• Deployment: Setup instructions, database configuration, and deployment instructions provided; incomplete features clearly identified.

11. Assumptions and Constraints

• Assumption: The application is single-tenant to Vinod Photography; all authenticated users are the studio operator accessing the studio's own private records. No differentiated permission model beyond authenticated access is required. (required_inference)
• Assumption: Team Member / Freelancer and Editor / Delivery Coordinator personas are maintained and tracked within the studio's records rather than given separate account-based visibility. (required_inference)
• Constraint: All data must persist across refresh, logout, and reopening. (explicit)
• Constraint: Use INR, Indian date formats, and Asia/Kolkata. (explicit)
• Constraint: Business records private; secure login, access controls, input validation. (explicit)
• Constraint: Never count a payment twice; prevent duplicates; preserve transaction history. (explicit)
• Constraint: Do not claim notifications active unless properly configured; explain external credential configuration. (explicit)
• Constraint: Clearly identify incomplete features; deliver the actual working application. (explicit)
• Default — not specified by user: Exact deployment target and hosting provider; exact push/email provider selection.

12. Glossary

• Booking: A wedding engagement record for a couple, with a unique booking ID, package, and one or more functions.
• Function: An individual event under a booking (engagement, pre-wedding, Haldi, Mehendi, wedding, reception, family function, custom).
• Team Member / Freelancer: A photographer, cinematographer, traditional photographer/videographer, drone operator, editor, assistant, or other freelancer in the reusable directory.
• Assignment: The link of a team member to a booking or function, with role and fee.
• Customer Payment: A partial or installment payment received from a couple against the package price.
• Staff Payment: A full or partial payment made to a team member for an assignment, including allowances.
• Installment Schedule: A customized plan of expected customer payments with due dates.
• Ledger: The running record of customer payments and balance for a wedding.
• Estimated Profit: Customer revenue actually received or contract revenue (labeled method) minus relevant expenses.
• Delivery Task: A step in the post-production workflow (backup, selection, editing, teaser, video, album, approval, printing, QC, final delivery).
• Receivable: Outstanding customer balance owed to the business.
• Payable: Outstanding amount owed to staff or vendors.
• PWA: Progressive web application.