Project
ELDA Wedding Sites
ELDA Wedding Sites on GitHub · Live at eldaweddings.info
Overview
ELDA Wedding Sites is a production-ready, full-stack web application built for a wedding services business. It covers three distinct surfaces — a polished public-facing site, a secure owner/admin intranet, and an invite-only client portal — each with its own routing layer, authentication model, and data scope.
This is the kind of system most developers outsource to a CMS or a SaaS platform. Every piece here is custom-built: the booking pipeline, the payment view, the report engine, the client plan workspace, and the automated admin triage system.
What It Does
The public site handles lead generation: ceremony packages, venue pages, catering, florals, a gallery, and a set of specific service request forms (/request/package, /request/venue, /request/catering, /request/florals). Submissions flow directly into the admin intranet for follow-up.
The admin intranet (/admin) is a fully featured operations dashboard: leads, bookings, transactions, service request intake, and a Report Studio that generates custom exports on demand. An Admin Autopilot module runs autonomous triage on stale bookings against configurable rule thresholds — without manual intervention.
The client portal (/client) is invite-only by default. Clients get a dashboard showing their plan selections, finance snapshot, and communication history — plus a Wedding Inspo board and a milestone-driven Wedding Plan workspace with required and custom tasks.
Core Features
Public-Facing Site
- Ceremony packages with expanded detail pages
- Venue gallery, florals, catering, and nearby attractions (Google Maps-linked)
- Booking request form and client portal entry point
- Planning Guide and Vow Renewals pages
- Contact form with service interest selection
Admin Intranet (/admin)
- Secure login/logout with owner and staff roles
- Dashboard with leads, bookings, and transaction metrics
- Luxury Operations Command Center: priority queue and concierge quick-action cards
- Contact response management with read state, notes, and selected service interests
- Booking management with status tracking and notes
- Payments/transactions view with summary cards and status filter
- Report Studio (
/admin/reports/studio): dataset/field/filter-driven custom reports with saved templates and CSV/HTML export - Admin Autopilot (
/admin/autopilot): rule threshold controls and autonomous stale-booking triage - Admin help center with step-by-step operational guides
- CSV exports for contacts, bookings, payments, and service requests
- Owner-only admin user management
Client Portal (/client)
- Invite-only email/password login (Google OAuth also supported)
- Dashboard with plan selections, finance snapshot, and communication history
- Wedding Inspo board for colors, themes, florals, and notes
- Wedding Plan workspace with milestones, required tasks, and custom tasks
- Auto-linking of bookings and contacts by client email
Tech Stack
| Layer | Technology |
|---|---|
| Backend | Python 3.11+ / Flask |
| ORM | Flask-SQLAlchemy / Flask-Migrate |
| Auth | Flask-Login + Google OAuth |
| Flask-Mail | |
| Database | PostgreSQL (production) / SQLite (local dev) |
| Frontend | Tailwind CSS, Vanilla JavaScript |
| Deployment | Railway (Gunicorn + Nixpacks) |
| Testing | pytest + Playwright (e2e) |
Architecture
The codebase follows a layered modular structure:
app/routes/*— HTTP routing and view orchestrationapp/services/*— shared business logic (attachment policy, email handling)app/models/*— persistence entities and relationshipsapp/utils/*— framework utilities
A full architecture diagram is maintained at docs/architecture.mmd / docs/architecture.png. Release and rollback procedures are documented in docs/RELEASE_ROLLBACK_RUNBOOK.md.
Why It Stands Out
Scope. Most portfolio projects are a CRUD app with one user type. This has three distinct user surfaces, each with its own auth model and data scope, all sharing a single database.
Admin Autopilot. The triage system doesn’t just display stale bookings — it acts on them autonomously against configurable rules. That’s the difference between a reporting tool and an operations tool.
Report Studio. Rather than hardcoded exports, the report engine lets the owner define datasets, fields, and filters at runtime, then save templates. That’s a feature decision, not just an implementation choice.
Production-ready deployment. Railway deployment with render.yaml, Gunicorn, PostgreSQL TLS, canonical host enforcement, rate-limited auth routes, and a full Playwright e2e test suite covering public, client, and admin surfaces.