Aircraft Rental: Request-to-Book with an Auto Logbook

Request-to-book, not instant booking

Renting an aircraft here is the fourth transactional vertical alongside classifieds, ferry and cargo. An owner lists a machine from their garage with a per-hour flight rate (wet or dry), an optional daily rate and daily minimum, a deposit, a currency, an availability window and pilot requirements. A renting pilot then sends a request for specific dates — the booking is never automatic.

Every request runs through a clear lifecycle: requested, approved, active, completed, with declined and cancelled as exits. The owner keeps full control and approves each pilot by hand, while the platform does the heavy lifting of checking eligibility before the decision is even on the table.

• Rate per flight hour (Hobbs/Tach), wet (fuel included) or dry
• Optional daily rate and per-day flight minimum
• Deposit held for the rental, in EUR, USD, GBP or CHF
• Availability: always, weekends only, or a custom schedule with blocked dates
• Listing statuses: draft, active, paused, archived

Two-sided verification: the pilot is checked, not just the aircraft

Ordinary rental boards verify a machine and stop there. Here the verify engine checks the renting pilot against the listing before the owner ever clicks approve. It reads licence, medical class, total confirmed hours, hours on type, checkout and insurance, and returns a per-item status of ok, low (below threshold or expired) or todo (not done yet).

The request therefore reaches the owner with the pilot's credentials already reconciled. A tolerant parser handles free-text licence and medical expiry — dates in different formats, or "lifetime" — mirroring the platform's currency engine, so one logic governs the whole product. Crucially, hours count both from a user's own aircraft and from records where they are marked pilot-in-command, so rented time itself feeds future eligibility.

• Requirements: licence, minimum total hours, minimum type hours, checkout, insurance
• Checkout is confirmed from a previous completed rental of the same aircraft by the same pilot
• Statuses per item: ok / low / todo
• Snapshot of terms at request time — rate, wet/dry, deposit and currency are frozen

Rented hours close the loop into your logbook

The defining feature is what happens on return. When the aircraft comes back, the system writes a sealed (hash) flight record into the aircraft's digital logbook with pilot-in-command set to the renter. Those rented hours become confirmed flight time for the pilot — the same currency that raises eligibility on other aircraft and reputation across the platform.

Billing is honest and physical: the owner logs Hobbs at handover (out) and at return (in), and flight time is the difference (or set manually). The charge is hours multiplied by the rate captured at request time; the deposit is returned on completion. Escrow is deferred honestly — the interface states plainly that payment and deposit will become automatic through the platform later, once the legal side is in place.

Deal room, chat and a hash-chained history

Both sides settle handover details inside a deal room with a chat built on a hash-chain: an append-only conversation plus system events, with the server recomputing chain integrity (verifyChain). The record of the deal is provable and immutable, unread messages are tracked per side, and a light chat polling keeps the room fresh while the tab is visible.

Identities stay protected: the counterparty is exposed as a handle, name and verified badge only — email is never handed out. The room header even shows the counterparty's reputation (score, level, stripes), and the listing card surfaces the aircraft's number of sealed logbook records, so a renter sees real history rather than a bare advert.

• Owner actions: approve, decline (with a reason), handover (Hobbs out), return (Hobbs in, fuel note, snags)
• Renter action: cancel before handover, in requested or approved states
• Gate: you cannot rent your own aircraft or duplicate an active request on one machine
• Email notifications for every event, debounced and respecting the notifyEmail setting

One cabin for renting out and renting in

The rental cabin has a single "Rent out / Rent in" switch. On the owner side it shows income and fleet-utilisation stats, incoming requests, active and upcoming rentals, and the fleet currently out. On the renter side it lists your own requests. A live rental-card preview renders while you fill the "List for rent" form, and location prefills from the aircraft's home aerodrome (locationIcao).

The storefront itself is server-rendered (ISR, tag rentals) with a grid of cards and a client island for interactivity, and the whole /rent section is bilingual EN/RU on every screen. The tone of the eligibility flow is deliberately humane: when a pilot is marginally short, the owner is prompted to approve with a caveat, request more hours, or offer an instructor flight — rather than a blunt refusal.