DEV3 Borrova – Rental Marketplace Laravel Script with Deposits, Date Availability & Claims (Renter & Owner Flutter Apps)

A self-hosted rental marketplace on Laravel 12 and Filament 4 with renter and owner Flutter apps: date-first search, serial-numbered units, deposits in escrow, handover codes, damage claims and payouts. Installer and demo data included.

by DEV3 TechnologiesVerified Author(0) 0 sales 0 viewsUpdated 04 Nov 2026

Video tour. Pick a section below to browse 113 screenshots in 21 sections.

Borrova is a rental marketplace script that you host yourself, built by DEV3 Technologies on Laravel 12 and Filament 4, with two Flutter apps: one for renters and one for owners. Owners list cameras, lenses, lighting, tools and furniture as serial-numbered units. Renters search by date, pay the rental and a refundable deposit, collect the item with a one-time code and bring it back. The site earns a commission from owners and a service fee from renters, and staff handle claims, verification and payouts from an admin panel. The demo city is a fictional place called Marrow Quay.

No live demo: 113 grouped screenshots (web, owner panel, admin, and both apps) and two video tours show the marketing site, the booking flow, the owner side and every admin screen. Install it with the bundled demo data to try each role on your own server.

Search and book by date

  • Search starts with dates. With a date range set, only items that have a free unit for every day are listed, each with an estimate for the stay. Filters cover category, price, instant book, delivery and distance, with a map view.
  • Each item has several units, each with its own serial number. The calendar shows free units and the price for every day. A unique key on unit and day means two renters can never be given the same unit, and the closest-fitting unit is chosen so long free stretches stay open.
  • Instant-book items hold a unit for a set number of minutes while the renter pays. Request items are held while the owner answers, then the renter pays within a time limit. Unpaid holds expire by themselves.
  • Items can set minimum and maximum days, lead time, a buffer after each booking, pickup and return times, and optional delivery within a radius.
  • Public pages show items at a shifted location, so an exact address stays private until a booking is made.

Rates, deposits and insurance

  • Daily, weekly and monthly rates, plus seasonal multipliers. A short rental never costs more than the weekly or monthly rate, and the same pricing maths is written twice, in PHP and in Dart, and checked against shared test vectors.
  • The quote lists rental, add-ons, delivery, optional damage cover, the service fee and tax, and shows the refundable deposit apart from them.
  • The deposit is a real second payment held in escrow. A booking confirms only when the rental and the deposit have both landed. If one fails, the other is refunded.
  • Cancellation follows each item's policy (flexible, moderate or strict), and the same refund numbers appear in a preview before the renter confirms.

Handover, return and claims

  • Pickup and return use a six-digit code that the renter shows and the owner enters, plus condition photos from both sides. Five wrong tries lock the code for ten minutes.
  • After the return the owner has a claim window. With no claim, the deposit is refunded in full. A claim needs photos, a reason and an amount no higher than the replacement value. The renter accepts or disputes it, silence counts as accepting, and staff decide disputes with the handover and return photos side by side.
  • Late fees come out of the deposit first. If the late rental collides with the next booking, Borrova first tries to move that booking to another free unit, and otherwise lists it on a Conflicts board for staff.
  • Extensions are limited to the same unit and are priced by repricing the whole new stay.
  • Optional damage cover has a renter deductible and a pool cap, and the insurance pool has its own ledger.

Owners

  • An owner applies, uploads documents and is approved by staff. The owner panel and the owner app both offer a month and agenda calendar per unit, day blocks, an item wizard with a live price preview, units and serials, seasonal rates, add-ons, requests with an expiry, handover and return, claims, earnings and payout requests.
  • Owners are paid after a settlement delay that starts at handover. Owner cancellations carry a penalty and a strike.

Admin panel

  • Roles for admin, operations, finance and support on one Filament panel. Groups: Rentals (bookings, overdue returns, conflicts, extensions, deliveries, an availability explorer), Trust (claims, owner KYC, renter verifications, no-shows, reviews), Catalogue (items, units, categories, add-ons), Finance (deposit ledger, charges, insurance pool, wallets, payouts, tax rates, four reports) and Settings.
  • The dashboard shows active rentals, starting and returning today, overdue, deposits held and open claims, plus a 3D Utilisation Dial: a ring of the next thirty days where each segment's height is the share of units booked.
  • Reviews are double-sided and revealed together, or after a set number of days.
  • The core also provides settings, roles, audit log, devices, wallets and a REST API with an OpenAPI document and reference page.

The two Flutter apps

  • Renter app: onboarding, sign-in, home with a date bar, search with date range, filters and map, item detail with a priced calendar, the booking wizard, payment with a hold timer, bookings, handover with a photo checklist, pickup code, delivery tracking, extend, cancel preview, claims, wallet, settings, Arabic and a tablet layout.
  • Owner app: dashboard, calendar with block days, requests with swipe actions, booking detail, handover and return codes, items and rates, the item wizard, damage claims, a driver map, earnings and payouts.
  • Both start in demo mode with their own data and switch to your server with two build flags.

What is included

  • The Laravel application with Composer packages and compiled assets already inside (no Node.js or Composer needed on the server), the renter and owner Flutter projects in apps/, the shared DEV3 packages, a web installer with demo or empty data, and documentation.
  • English, with an Arabic translation and right-to-left layout for navigation and the main flows, and light and dark themes.

Good to know

  • Payments, SMS and push were not tested with live accounts. The Stripe, PayPal and Razorpay drivers, push notifications and SMS exist as drivers. The simulated gateway is the default, push and SMS use simulated or log drivers, and the money rules were tested against the simulated gateway only. Run your own test payments before taking real ones.
  • The apps were not tested on physical devices. They build as a debug Android package and run on the iOS simulator. Expect to do your own end-to-end pass on a real phone once you point them at your server.
  • Photos in the apps are generated tokens. The renter and owner apps send generated photo tokens for condition and claim photos rather than uploading pictures from the device camera. The API accepts real files, but the apps do not yet send them.
  • Two owner features are missing from the API. There is no endpoint for owners to reply to a review (the owner app offers rating the renter instead) and no claims list for owners (the app builds its claims screen from returned bookings).
  • Arabic is partial. It covers navigation and the main flows. Some long body copy stays English.
  • Lighthouse mobile was not measured.
  • Real-time: the apps refresh by polling, not a live socket.
  • Scope: the deposit is a real charge, because the payment layer has no card pre-authorisation. Borrova does not verify identity documents automatically, staff review them.
  • Name: Borrova is a working name checked by a web search only, not a trademark clearance. Check it before you launch under it.
  • No hosted demo. All brands, people and items in the screenshots are fictional.

Quality checks

Borrova 1.0.0 passed the seven release gates of the DEV3 Laravel suite: static analysis, 245 Pest tests with 6,490 assertions, a front-end size budget, migrations and seeding, a headless-browser pass over 45 pages with four booking-race and availability checks against MySQL, an installer test from the zip, and a secret scan. The renter app passed 147 tests and the owner app 130 tests, with analysis and debug Android and iOS simulator builds.

How it's built

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

The engineering behind Borrova: Laravel 12 and Filament 4 on a shared core, one row per unit and day as the allocation truth, pricing maths shared with Dart, a deposit held as a second payment, and claims and late returns resolved by rules.

The problem it solves

A rental marketplace is a booking engine with money attached. Two renters tapping book on the last camera must not both win, and a 1-unit item and a 3-unit item need different answers from the same code. A long rental should never cost more than the weekly rate, and the app, the site and the server must quote the same number. The card gateway has no pre-authorisation, so the deposit has to be a real charge that can be returned in full or split. A late return can collide with the next renter's booking, a payment can arrive after a hold has lapsed, and a damage claim has to divide cost between the deposit, late fees, an insurance pool and an amount the renter still owes. Borrova had to settle each of these on the server first, then offer them through one API to the website and two apps.

Architecture and approach

Borrova is a Laravel 12 application with three Filament 4 panels: /admin for staff (admin, operations, finance and support), /owner for item owners and /account for renters. The public site is Blade with a small JavaScript layer and lazy-loaded three.js scenes. The renter and owner Flutter apps call the same /api/v1 endpoints, and a token carries only the ability of its own app. Rules live in services under app/Services, so the web, the API and the admin share them.

Rules in services

  • Availability. A unit_days table holds one row per unit and day with a unique key on both. AvailabilityService::allocate runs under a lock on the item, picks the closest-fitting free unit, and tries the next unit if the database reports a duplicate. The unique key is the final guarantee, the lock only reduces contention. Expired holds are cleared in their own committed transaction first.
  • Pricing. RentalPricing is a pure function: tiered daily, weekly and monthly rates, seasonal multipliers per day, one rounding at the end, and a rule that a shorter stay never costs more than the longer tier. A Dart port mirrors it for the apps, and JSON fixtures for rental, cancel and claim cases run in both stacks.
  • Booking and money. A booking moves through requested, awaiting payment, confirmed, active, returned and completed. The deposit is a second Payment, and a booking confirms only when the rental and the deposit have both succeeded. Card money is applied on the payment-succeeded event, ledger keys carry the payment id, and late, stale or duplicate money is refunded at once.
  • Handover. HandoverService checks condition photos from both sides and a six-digit code. The code is returned only to the renter's API, stored encrypted, and locks after five wrong tries.
  • Cancellation and late returns. CancellationService computes the refund band from the item's policy and the time to pickup, and the preview uses the same code. LateCheck adds a late fee once per day, then tries to move the next booking to another unit before flagging a conflict for staff.
  • Claims. ClaimService splits an approved amount between the renter's deductible, the insurance pool, late fees and the deposit, opens a charge for any shortfall and refunds the rest.

Scheduler

One cron line runs borrova:expire, borrova:late-check, borrova:settle, borrova:complete and borrova:reveal-reviews. Queues default to sync, so no worker is required to start.

The apps

Both Flutter apps have a built-in mock of the API with the same quote, availability and refund maths, so they run in demo mode on their own. Two build flags point them at a real server. They poll for changes rather than hold a socket.

Quality gates and results

Borrova 1.0.0 passed all seven release gates of the DEV3 Laravel suite:

  • Tests: 245 Pest tests with 6,490 assertions, including a suite for the fixes found in a review of the booking, refund and claim rules.
  • Races: SQLite cannot prove a race, so a smoke script fires eight parallel bookings at MySQL: a 1-unit item gives exactly one booking, a 3-unit item exactly three, and a repeated client key gives one.
  • Browser pass: 45 pages in a headless browser, plus four booking-flow and availability-explorer checks.
  • Installer and secrets: the installer ran from the zip, and the secret scan was clean.
  • Apps: the renter app passed 147 tests and the owner app 130, with analysis and debug Android and iOS simulator builds.

Limits: payment, push and SMS drivers were not run against live accounts, the apps were not run on physical devices, the apps send generated photo tokens rather than device photos, owners have no review reply or claims list endpoint, Arabic covers navigation and main flows, and Lighthouse mobile was not measured.

Tech stack

Area Technologies
Backend Laravel 12, Filament 4 panels, REST API under /api/v1, Scheduler commands, Sanctum app tokens
Booking engine Unit-day allocation, Rental pricing service, Handover service, Cancellation service, Claim service, Late-return check
Frontend Blade, Tailwind CSS 4, Vite, three.js exploded-kit hero, Utilisation Dial widget
Mobile Flutter renter app, Flutter owner app, Built-in API mock, Shared Dart pricing port
Data MySQL 8, SQLite, Integer money, Demo and empty seeders
Integrations Stripe, PayPal, Razorpay drivers, Push and SMS drivers, Simulated gateway default

Inside the build

Exploded kit: A cinema camera floats apart along its axis with coral leader lines to spec labels, above a turning ring calendar. Exploded kit — A cinema camera floats apart along its axis with coral leader lines to spec labels, above a turning ring calendar.

Reassemble: The parts snap together and the serial plate lights up: unit 3 of 5. Reassemble — The parts snap together and the serial plate lights up: unit 3 of 5.

Guides & articles

Practical guides and engineering write-ups for DEV3 Borrova.

Rental marketplace script: 7 things to check before you pick one

Last updated
Rental marketplace script: 7 things to check before you pick one: DEV3 Borrova

Rental marketplace scripts tend to share one demo: a grid of cameras, a date picker and a book button. The differences show up in the first busy weekend, when two renters pay for the last lens within the same second, when a three-day rental turns out to cost more than the weekly rate, when a renter keeps the drill two days past the return date and the next renter is already on the way, or when a damage claim is bigger than the deposit and nobody knows who owes what. This guide lists seven things worth testing before you choose a self-hosted rental script, and how Borrova, built on Laravel 12 and Filament 4 with two Flutter apps, handles each one.

The Borrova booking calendar: every day shows its free units and its price

1. Can two people book the same unit?

Ask how availability is stored. A script that checks "is anything booked between these dates?" and then saves is open to a race. Look for a rule the database itself enforces.

Borrova keeps one row per unit and day, with a unique key on the pair. An allocation runs under a lock on the item, picks the closest-fitting free unit so long stretches stay open, and tries the next unit if the database refuses a duplicate. Items can have several serial-numbered units, so a three-unit item can take three bookings for the same days and no more. The test suite cannot prove this on SQLite, so the browser smoke script fires eight parallel bookings at MySQL and checks the counts.

2. Does pricing behave across rate tiers?

Daily, weekly and monthly rates are common. Check the edges: a six-day rental should not cost more than a week, and seasonal prices should apply to the days they cover, not the whole stay.

In Borrova a stay is priced day by day with the highest seasonal multiplier for each date, rounded once at the end, and capped by the weekly or monthly tier. The same maths runs in PHP and in the Dart apps, and shared test vectors run in both, so the quote on the phone matches the quote on the server.

The live quote in Borrova: rental, add-ons, cover, fee and tax, with the refundable deposit shown apart

3. How is the deposit actually held?

"Deposit" can mean a card pre-authorisation, a wallet hold or a plain charge. Each behaves differently when a payment fails halfway.

Borrova's payment layer has no pre-authorisation, so the deposit is a real second payment held in escrow. A booking confirms only when both the rental and the deposit have succeeded, and if one fails the other is refunded. Money that arrives after a hold has lapsed is refunded at once. The simulated gateway is the default, and the Stripe, PayPal and Razorpay drivers were not tested with live accounts.

4. Is the handover recorded?

Disputes start at pickup. Look for condition photos from both sides and some proof that the item changed hands.

Borrova uses a six-digit code. The renter sees it in the account or app, the owner types it, and both sides add condition photos first. Five wrong tries lock the code for ten minutes. The return works the same way. Staff can see handover and return photos side by side when they decide a dispute.

Handover photos and return photos side by side in the Borrova admin

5. What happens when a claim exceeds the deposit?

A script that only refunds the deposit or keeps it is not enough. You want a claim process with evidence, a time limit and a clear split.

In Borrova the owner has a claim window after the return. A claim needs photos, a reason and an amount no higher than the replacement value. The renter accepts or disputes it, and silence counts as accepting. Late fees come out of the deposit first. The renter's share is limited by an optional damage cover with a deductible, an insurance pool pays the rest up to a cap, and anything the deposit cannot cover becomes a charge due in seven days. An unpaid charge blocks new bookings.

6. What if the item comes back late?

Late returns hurt the next renter. Check whether the system notices, charges, and does something about the collision.

Borrova checks every fifteen minutes. After a grace period it adds a late fee for each started day, takes it from the deposit first, and looks at the next booking on that unit. If another unit is free it moves the booking and tells both people. If not, the booking lands on a Conflicts board where staff can rebook or cancel with a full refund.

The Borrova Conflicts board: a late return colliding with the next booking

7. Are there apps for both sides, and how were they tested?

Renters and owners do different jobs. Ask whether the owner has an app, and what the apps were tested against.

Borrova includes a Flutter renter app and a Flutter owner app. Both start in demo mode with their own data, and two build flags point them at your server. The renter app passed 147 tests and the owner app 130, and both build as a debug Android package and for the iOS simulator. They were not tested on physical devices. The apps send generated photo tokens for condition photos rather than camera pictures, although the API accepts files. Owners cannot yet reply to reviews from the API, and there is no claims list endpoint, so the owner app builds its claims screen from returned bookings.

See it in action

The video tour goes from search by date through booking, owner approval and handover, to a late return, a claim and the deposit split in the admin panel.

Video tour of Borrova

What else to compare

  • Cancellation: flexible, moderate and strict policies per item, with a refund preview that uses the same code as the real refund.
  • Verification: owner documents and renter ID checks are reviewed by staff, and items can require a verified renter.
  • Delivery: optional delivery within a radius, with a driver map.
  • Admin: roles for admin, operations, finance and support, a deposit ledger, an insurance pool ledger, four reports and a 3D utilisation dial.
  • Languages: English, plus Arabic with right-to-left layout for navigation and the main flows. Some long body copy stays English.
  • What was not verified: live payment, SMS and push accounts, physical devices and Lighthouse mobile.
  • Quality: Borrova 1.0.0 shipped with 245 Pest tests (6,490 assertions), a headless-browser pass over 45 pages, an installer test from the zip and a clean secret scan.

Instead of a live demo, the listing has 113 grouped screenshots and two video tours, and the "How it's built" section explains the architecture.

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?

More from this author

View all

Related in Web Scripts & Software

View all