DEV3 Technologies home

DEV3 Duneholt – Vacation Rental Marketplace Laravel Script with Nightly Pricing, iCal Sync & Guest/Host App

A self-hosted vacation-rental marketplace on Laravel 12 and Filament 4: nightly calendar pricing, instant and request-to-book, deposits and claims, iCal sync and host payouts. Web installer and demo data included. Flutter app source included.
by DEV3 TechnologiesVerified Author(0) 0 sales 0 viewsUpdated 13 Nov 2026

Video tour. Pick a section below to browse 48 screenshots in 6 sections.

App & phone tours

Tap play to watch each app. Nothing downloads until you do.

  • Mobile web0:25
  • Guest app1:49

Duneholt is a vacation-rental marketplace you host yourself, built by DEV3 Technologies on Laravel 12 and Filament 4, with a Flutter app that works for guests and, in host mode, for hosts. One operator (a regional holiday-homes marketplace, or a property manager's direct-booking brand) runs it and is the merchant of record. The demo business is a fictional operator, Saltgrass Stays, with 240 homes along the invented Corrin Coast.

No live demo: about 33 grouped web screenshots, 16 app screenshots and video tours show the marketing site, search and checkout, the host panel, the admin panel and the app. Install it with the bundled demo data to try every role on your own server.

What guests get

  • Search by place, dates and guests, as a list or on a coast map, with filters and the price per night for the dates chosen.
  • A full price breakdown before booking: nights, length-of-stay discount, cleaning fee, extra-guest fee, service fee, VAT and tourist tax, each on its own line.
  • Instant book (the dates are held for ten minutes while you pay) or request to book (the host replies within 24 hours and the card is charged on acceptance).
  • A check-in guide that unlocks before arrival with the door code, Wi-Fi and directions, trips, cancellation with a per-line refund preview, date changes re-priced at current rates, messages and reviews that reveal when both sides have written or after 14 days.

What hosts get

  • A nightly calendar: base and weekend prices, seasons, custom nights, length-of-stay discounts, minimum and maximum nights, closed-to-arrival and departure days, advance notice and preparation days. Select a range and edit it in one step.
  • iCal import and export per listing, with conflicts flagged against confirmed bookings.
  • Bookings and requests, messages, damage claims with photo evidence against a deposit, earnings and payouts released 24 hours after check-in, co-hosts with per-area permissions, API keys and webhooks.

What the operator gets

An admin panel with a listing review queue, host verification (ID documents on a private disk), bookings, payments, refunds, deposits, payout batches, a tourist-tax report by town, claim decisions, reports, a pricing simulator that shows where each night's price came from, destinations, settings and a live Tide Chart of the booking pulse.

The app (Flutter source included)

One app with guest and host modes: explore, search, listing detail, the price sheet, the hold countdown, request to book, card and 3-D Secure steps, trips and the check-in guide, host Today, calendar, requests, claims and earnings. It runs in demo mode out of the box and points at your site when you set its URL. Its price maths is a port of the server's and is checked against 72 shared test vectors.

Built for correctness

Pest tests (338 passing) cover the price engine, calendar locks, request to book, cancellations and date changes, deposits and claims, payouts and iCal imports; party isolation is checked on every route that names a record. A MySQL race suite runs real parallel requests: five guests on overlapping nights, an iCal import against a hold, accept against expiry, double payout release, double cancel and two ticks on a due deposit.

Good to know

  • A vacation-rental marketplace you operate, or a property manager's own direct-booking site. It is not a hotel system and not a multi-company SaaS.
  • Calendar sync with other platforms is iCal import and export per listing (availability only, about a 30-minute delay, so a double booking across platforms is possible inside that window). There is no channel-manager API and no rate push.
  • Payments, deposits and host payouts are simulated until you connect a gateway. Deposits are charged then refunded (no card holds). You are the merchant of record and responsible for payment licensing where you operate.
  • Occupancy and tourist taxes are configurable rates; there is no automatic tax filing. Pricing is rule-based (no AI pricing). No smart-lock drivers: the code is shown from the listing or typed by the host, and a signed webhook fires before check-in.
  • The app was verified in simulator builds, tests and against the live API, not on a real device. Publishing to the app stores is your step (guide included).

Requires PHP 8.2+, MySQL 8 or MariaDB 10.6+ for a live site (SQLite for evaluation) and a cron entry. Flutter 3 is needed only to build the app.

How it's built

Architecture, stack, key decisions and the quality gates DEV3 Duneholt passed before release.

The engineering behind Duneholt: one row per listing night locked in a single transaction, integer-minor-unit price maths shared with the Flutter app, hold-then-pay bookings, deposits and claims, and iCal imports that never overwrite a confirmed stay.

The problem it solves

A rental calendar looks simple until guests arrive together. Five people try the same weekend at the same second. An iCal feed from another platform lands while a card is being charged. A host accepts a request in the same second it expires. The price a guest saw has to be the price charged: nights, seasons, length-of-stay discounts, fees, VAT and tourist tax rounded the same way on the server and in the app. Deposits are charged and refunded, host payouts wait for check-in, and a cancellation has to refund each line by its own rule.

Architecture and approach

Duneholt is a Laravel 12 application with Filament 4 panels at /admin and /host, Blade pages for the marketing site, search, checkout and trips, a REST API under /api/v1 with scoped keys and webhooks, and a Flutter app that talks to /api/v1/app. It builds on the shared DEV3 Laravel core for settings, roles and the web installer.

Every night is a row in listing_nights. Taking, confirming and releasing nights happens under one lock, so only one of five simultaneous guests gets the dates. A booking is hold-then-pay: ten minutes of held nights, then payment, or a request the host answers within 24 hours.

All money goes through one pure class, StayMath, in integer minor units with half-up rounding. The Flutter app ports the same file and both run 72 shared test vectors, so the price shown on a phone is the price the server charges. Cancellations refund line by line by tier, date changes re-quote at current prices under the lock, and payouts release 24 hours after check-in in absolute time so daylight-saving changes do not move them.

iCal imports key blocks by UID. An event that overlaps a held or booked night becomes a flagged conflict and never touches the booking.

Quality gates and results

Duneholt 1.0.0 passed the seven release gates on the final code: Larastan level 6 with 0 errors, 338 Pest tests, and a MySQL race suite with real parallel requests that stayed green across repeated runs. The demo seeds 240 listings, about 21,000 stays and a reconciliation check that fails loudly if bookings, nights and payouts do not tie out.

Tech stack

Area Technologies
Application Laravel 12, Filament 4, Blade, REST API
Data MySQL 8, Row locks, Integer money
Mobile Flutter, Riverpod
Quality Pest, Larastan level 6, MySQL race suite

Inside the build

Night by night: the hero with a dusk porch, the price sheet on a phone and the host calendar behind it. Night by night — the hero with a dusk porch, the price sheet on a phone and the host calendar behind it.

Nightly pricing: base, weekend, seasons and custom nights, with length-of-stay discounts. Nightly pricing — base, weekend, seasons and custom nights, with length-of-stay discounts.

Guides & articles

Practical guides and engineering write-ups for DEV3 Duneholt.

Vacation rental software: 6 things to check before you pick one

Last updated
Vacation rental software: 6 things to check before you pick one: DEV3 Duneholt

A rental marketplace loses trust in small gaps: the same weekend sold twice, a price in the app that differs from the price charged, a deposit nobody can explain, a host paid before the guest arrived. Here are six things to check before you pick vacation rental software, with DEV3 Duneholt as the worked example.

Duneholt home page: a timber porch at dusk beside the headline and call to action

Video tour: search, a listing, checkout, the host calendar and the admin panel

1. Can two guests ever book the same night?

Ask what happens when five people pick the same weekend in the same second. The right answer is one booking and four clear "dates no longer available" messages. Duneholt keeps one row per listing night and takes, confirms and releases nights under a single lock, and its race suite runs real parallel requests against MySQL to prove it.

2. Is pricing night by night?

Real rentals price weekends, seasons and single nights differently, with discounts for longer stays and minimum nights. Check that the calendar supports base and weekend prices, seasons, custom nights and length-of-stay discounts, and that the guest sees every fee on its own line.

Nightly pricing: base, weekend, seasons and custom nights with length-of-stay discounts

3. Does the app show the price the server charges?

Prices drift when the app and the server each do their own maths. Duneholt keeps all money in one class using whole minor units, and the Flutter app ports the same file and runs the same 72 test vectors.

4. Instant book, request to book, or both?

Some hosts want instant bookings, others want to approve each guest. Duneholt holds dates for ten minutes while an instant guest pays, and gives request-to-book hosts 24 hours to reply, charging the card only on acceptance.

Instant or request to book: a ten-minute hold or a 24-hour reply window

5. How are deposits, claims and payouts handled?

Look for a deposit the guest can see, a claim flow with photo evidence and a staff decision, and payouts that wait until after check-in. In Duneholt deposits are charged then refunded, claims are decided by your trust team, and host payouts release 24 hours after check-in.

Deposits and claims: evidence, the guest's reply and the staff decision

6. What does calendar sync really do?

Be wary of promises of perfect sync. Duneholt imports and exports iCal per listing: availability only, with a delay of about 30 minutes, so a double booking across platforms is possible inside that window. A conflict with a confirmed booking is flagged, never overwritten. There is no channel-manager API and no rate push.

iCal sync: feeds, run log and conflicts

Know the limits

Payments, deposits and payouts are simulated until you connect a gateway, you are the merchant of record, and taxes are configurable rates with no automatic filing. The Flutter app source is included; publishing to the stores is your step.

Frequently asked questions

The complete source code (version 1.0.0) as a download from your account, with the setup and usage guides shown on this page. You can modify the code to suit your product.

Buying guides: Laravel scripts with Filament panels and a web installer · Next.js or Laravel for a SaaS script?

Questions about this product (0)

Answers from the DEV3 team and the community.

Ask a question

No questions yet.

Wondering about setup, licensing or customisation? Ask, and the DEV3 team will help.

More from this author

View all

Related in Web Scripts & Software

View all