Laravel Booking Platform Development

IROUDA MONT BLANC ÉVASION – V1 BOOKING PLATFORM

PROJECT OBJECTIVE

Build a fully functional, production-ready Laravel booking platform for Irouda Mont Blanc Évasion. This is not a mockup/prototype. V1 must accept real bookings and payments and be commercially usable for the winter season.

The architecture must be clean, secure, maintainable and scalable so future V2/V3 features, including multi-company/subcontractor functionality, can be added without rebuilding the core system.

1. CUSTOMER BOOKING FLOW

The complete booking flow must support:

• One-way or round trip
• Pickup location
• Destination
• Transfer date/time
• Return date/time when applicable
• Number of passengers
• Vehicle selection
• Automatic price calculation
• Additional options
• Customer/travel information
• Booking summary
• Terms acceptance
• Online card payment
• Booking confirmation
• Automatic confirmation email
• Unique booking reference (example: IRO-2026-0001)

Pickup locations may include Geneva Airport, Lyon Airport, Grenoble Airport, train stations, hotels and custom addresses.

Destinations will follow Irouda’s pricing grid (Chamonix, Morzine, Avoriaz, Megève, Les Gets, Tarentaise resorts and other configured destinations).

Admins must be able to add/edit/disable pickup locations and destinations without developer intervention.

2. VEHICLES

Vehicle categories include:

• Car
• Van
• Minibus
• Bus/Coach

Each vehicle/category must support name, photo, capacity, description and applicable pricing.

Vehicles must be manageable from admin: add, edit, disable, change photo/category/capacity and manage availability.

The system must not be limited to a fixed number of vehicles.

Where possible, only vehicles compatible with passenger count should be proposed.

3. PRICING

Automatic pricing must follow:

Pickup → Destination → Vehicle → One-way/Round trip → Options/Supplements → Final Price.

Irouda’s existing pricing grid must be integrated.

Admin must be able to add/edit prices without developer intervention.

Admin must also have manual price override for special journeys, negotiated hotel rates, custom requests or exceptional transfers.

The final price must be clearly shown before payment.

4. CUSTOMER/TRAVEL INFORMATION

Collect at minimum:

• First/last name
• Email
• Phone
• Passenger count
• Flight number/airline/arrival time when applicable
• Train information when applicable
• Hotel/address
• Notes/special instructions

5. OPTIONS

Support configurable options such as:

• Baby seat
• Booster seat
• Ski equipment
• Special/oversized luggage
• Other special requests

Options may be free or paid and additional options must be addable later.

6. PAYMENT

Integrate a secure online card payment provider.

Payment statuses should include:

• Paid
• Pending
• Failed
• Cancelled
• Refunded where supported

Sensitive card information must never be stored directly on Irouda servers.

7. CONFIRMATION & EMAILS

After successful booking/payment, display a confirmation page and automatically email the customer.

Confirmation includes booking reference, customer, route, pickup/destination, dates/times, return details, passengers, vehicle, options, total amount, payment status and Irouda contact information.

Irouda admin must also receive an automatic new-booking notification with the main booking details.

8. TERMS & CONDITIONS

Customer must explicitly accept Terms & Conditions/booking conditions before completing the booking.

Acceptance must be mandatory and recorded with the booking.

9. ADMIN DASHBOARD

Secure authenticated admin area.

Dashboard must show at minimum:

• Total bookings
• New bookings
• Confirmed bookings
• Upcoming bookings
• Completed bookings
• Cancelled bookings
• Revenue generated through the platform

No complex analytics are required for V1.

10. BOOKING MANAGEMENT

Admin must see complete booking details including reference, customer/contact information, pickup, destination, dates/times, return, passengers, vehicle, options, price, payment status, booking status and creation date.

Booking statuses:

• New
• Confirmed
• Assigned
• In Progress
• Completed
• Cancelled

Admin must be able to modify bookings, including customer details, pickup/destination, dates/times, passengers, vehicle, options, price and notes.

Cancelled bookings must remain recorded rather than being deleted.

11. MANUAL BOOKINGS

Admin must be able to manually create bookings received through:

• Phone
• WhatsApp
• Email
• Hotels
• Conciergeries
• Travel agencies
• Direct customers

Manual bookings must use the same booking structure as online bookings.

12. AVAILABILITY / DOUBLE-BOOKING PROTECTION

The system must help prevent vehicle scheduling conflicts.

If a vehicle is already assigned to an incompatible booking at the same time, the system must either prevent assignment or clearly warn the administrator.

A complex automatic fleet scheduling algorithm is not required for V1.

13. CUSTOMER DATABASE / BASIC CRM

Securely store:

• First name
• Last name
• Email
• Phone
• Booking history

Admin must be able to view previous bookings associated with customers.

No advanced CRM is required for V1.

14. SEARCH & FILTERS

Admin must be able to search/filter bookings by relevant criteria including:

• Booking reference
• Customer
• Date
• Destination
• Booking status
• Payment status

15. DATA EXPORT

Admin must be able to export booking/customer data in CSV and/or Excel format so Irouda retains independent access to its business data.

16. HOTELS / PARTNERS

The booking interface must be simple enough for hotels, conciergeries, travel agencies and tourism partners to make bookings for their customers using a booking link.

A complete partner portal/commission system is NOT required for V1 and may be developed later.

17. LANGUAGES

Minimum languages:

• English – PRIMARY
• French – SECONDARY

Users must easily switch languages. Architecture should allow additional languages later.

18. RESPONSIVE DESIGN

The customer booking system must work correctly on:

• Smartphones
• Tablets
• Desktop computers

Mobile usability is essential. Admin interface must also remain usable on common screen sizes.

19. SECURITY

Follow standard Laravel/web security practices including:

• Secure admin authentication
• Secure password storage
• Input/form validation
• Protection against common web vulnerabilities
• Secure payment integration
• Appropriate customer-data protection

20. TECHNOLOGY & OWNERSHIP

Use clean, maintainable, scalable Laravel architecture.

V1 must not be a temporary system requiring a complete rebuild for future development.

Irouda must have access/ownership of the complete project deliverables, including relevant source code, database and configuration/documentation required to deploy and continue development.

The platform must not permanently depend on the original developer for basic operation.

21. FUTURE MULTI-COMPANY ARCHITECTURE

Long-term workflow:

Booking → Irouda receives booking → Irouda performs transfer OR, when capacity is insufficient, the transfer can later be assigned/subcontracted to another transport company.

The complete multi-company marketplace is NOT required in V1, but V1 architecture must not prevent its future implementation.

22. OUTSIDE V1 / FUTURE V2-V3

These advanced functions are NOT required for V1 and must not delay launch:

• Full driver application
• Real-time GPS/customer driver tracking
• Automatic driver dispatch
• Complete multi-company marketplace
• Advanced subcontractor/partner portals
• Automated inter-company commissions
• Advanced accounting/invoicing
• Advanced CRM
• WhatsApp/marketing automation
• Email campaigns
• Loyalty/referral systems
• Public API
• AI features
• Dynamic pricing
• Advanced fleet optimization

23. REQUIRED END-TO-END CUSTOMER FLOW

Customer:
Website → One-way/round trip → Pickup → Destination → Date/time → Passengers → Vehicle → Options → Automatic price → Customer/travel details → Summary → Accept Terms → Online payment → Unique booking reference → Confirmation page/email.

24. REQUIRED END-TO-END ADMIN FLOW

Irouda:
Receives booking/notification → Booking appears in dashboard → Views payment → Opens/edits booking → Changes status → Manages/cancels booking → Creates manual bookings → Manages vehicles → Manages destinations → Manages pricing → Searches/filters bookings → Exports data.

25. V1 DELIVERY / ACCEPTANCE

V1 is considered delivered only when the agreed features are functional and the complete booking process can be tested end-to-end.

The delivered V1 must be:

• Functional and production-ready
• Deployed
• Connected to the database
• Mobile responsive
• Connected to the payment system
• Able to process real bookings/payments
• Able to send automatic emails
• Fully manageable through the admin dashboard

V1 is NOT considered complete if it is only a design, mockup, static pages, incomplete booking form, demonstration, or system unable to process a complete real booking.

FINAL OBJECTIVE

Launch a reliable commercial V1 for Irouda’s winter season:

LAUNCH → REAL BOOKINGS → REVENUE → CUSTOMER/PARTNER FEEDBACK → V2/V3 IMPROVEMENTS.

This scope defines the required V1 functionality and should be treated as the reference for development, testing and delivery.