WeddingLot — the spec

WeddingLot is an internal operations tool for solo wedding-decor rental owners. It replaces the spreadsheet-and-inbox chaos of managing physical inventory with a single loop: list items, field requests, confirm bookings, collect money, and track condition — all without a team.

Decisions locked

The core loop

1. Owner adds a decor item to the inventory database, sets its rental price, and marks its available date windows.
2. A client submits a rental request (date, items, event location); the system checks availability in real time.
3. WeddingLot auto-generates a quote from the item database and sends it to the client via SMS or email.
4. Owner confirms the booking in one tap; client receives an instant confirmation with deposit instructions.
5. Payment and deposit are collected and logged against the booking.
6. At item checkout and return, the owner completes a condition checklist; the record is attached to that booking.

v1 scope

Visual Inventory Calendar — Displays each item's availability as a colour-coded timeline; blocks dates as bookings are confirmed. Lives on the Inventory screen.

Condition Checklist — A per-item form completed at checkout and again at return, capturing condition notes and flagging discrepancies. Lives on the Booking detail screen.

SMS/Email Booking Confirmations — Automatically fires a confirmation message to the client the moment a booking is confirmed, including event date, items rented, and deposit status. Triggered from the Booking confirmation flow.

Automated Quote Generator — Pulls item pricing from the database, applies rental duration, and outputs a formatted quote ready to send without manual calculation. Lives on the New Booking screen.

Payment and Deposit Tracking — Records deposit collected, balance due, and payment date against each booking; flags overdue balances. Lives on the Booking detail and Payments screens.

Deliberately later

• Delivery route optimizer — multi-event logistics only become a bottleneck once booking volume justifies it; routing complexity in v1 distracts from core confirmation speed.
• Damage claim documentation with photos — photo upload infrastructure adds scope; the v1 condition checklist captures the data needed to build this properly in v2.
• Revenue dashboard by item and season — meaningful only after enough bookings exist to surface patterns; 30-day launch target is customer acquisition, not analytics.

Data model sketch

• users — id, name, email, phone, business\_name, plan\_status
• inventory_items — id, owner\_id, name, category, description, rental\_price\_per\_day, quantity, thumbnail\_url
• availability_blocks — id, item\_id, start\_date, end\_date, status (available / booked / held)
• bookings — id, owner\_id, client\_id, event\_date, status, quote\_total, deposit\_amount, deposit\_paid, balance\_due
• booking_items — id, booking\_id, item\_id, quantity, unit\_price
• condition_checks — id, booking\_id, item\_id, check\_type (checkout / return), notes, checked\_at
• payments — id, booking\_id, amount, payment\_method, paid\_at, type (deposit / balance)
• clients — id, owner\_id, name, email, phone, event\_date, notes

Screens

• Dashboard — At-a-glance view of upcoming bookings, outstanding deposits, and items due for return today.
• Inventory — Full item list with the visual availability calendar; entry point for adding and editing items.
• New Booking / Quote — Request intake form that triggers the automated quote generator and sends it to the client.
• Booking Detail — Full record for one booking: items, pricing, payment status, and condition checklists for checkout and return.
• Payments — Ledger of all deposits and balances across bookings, with overdue flags.
• Clients — Lightweight CRM listing client contact details and booking history.
• Settings — SMS/email notification templates, business details, and payment configuration.

How to use this document

• Bring it into Mind Palace, where the guided platform and its AI coach pick up from exactly this document and build the product with you step by step.
• Hand it to a developer as the complete v1 brief — scope, data model, and screens are defined; no further discovery required before work starts.
• Keep it as the single source of truth while you build, pinning every feature decision and scope debate back to what is written here.