Discovery & data contracts
Mapped the rental workflow, the tariff model, and the safety obligations; agreed request/response data contracts with the client-side accounting and payment infrastructure so both teams could build in parallel.
Case study · Travel & Leisure · Mobile
MakeWake — self-service catamaran & boat rental app
How we shipped a self-service watercraft rental app for the US and EU leisure market — a geolocated fleet, QR unlock at the dock, a vessel catalog with real-time availability, automated time-based billing through a payment aggregator, and a write-back to the operator's accounting backend. After launch the operator reported repeat bookings up 30% and profit up 45% as the manual, attendant-driven rental desk turned into a one-tap flow.
The brief — turn a manual rental desk into a one-tap flow
The MakeWake operator ran a lakeside watercraft fleet — catamarans, rowboats, and small powered craft — the old way: a queue at a desk, a paper logbook, an attendant taking cash and reading a clock to total each trip by hand. It did not scale on a busy weekend, it leaked revenue on under-counted minutes, and it gave the operator no clean view of utilization or repeat customers. The brief was to make renting a craft feel like unlocking a scooter: open the app, see the fleet on the nearest lake, pick a vessel, agree to the safety rules, scan the QR code on the hull, and go. Off-the-shelf booking plugins failed two acceptance tests immediately — none of them could meter a live trip against a physical asset with a QR unlock, and none could write each completed rental back into the operator's existing 1C accounting system without a brittle nightly export. We built MakeWake from first principles as a native mobile app for the US and EU leisure market: a thin client wrapped around a real-time availability engine, automated time-based billing through a custom software development backend, and agreed data contracts into the operator's accounting infrastructure. The build sits inside our travel & leisure practice and is positioned for audiences across the US and EU under GDPR and CCPA expectations from day one.
Project highlights
Geolocated fleet discovery
QR unlock at the dock
Vessel catalog with type & capacity filters
Real-time availability — no double-booking
Automated time-based billing
Multi-method payment via aggregator
Mandatory life-jacket safety flow
1C accounting write-back · US & EU launch
By the numbers
The headline outcomes the operator reported after launch, plus delivery facts from the MakeWake build across the mobile client, the availability engine, and the accounting integration.
+30%repeat bookings after launch — the headline metric reported by the operator
+45%profit reported by the operator as manual counting and idle dock time fell away
1-scanQR unlock from cold app open to a metered trip on a specific vessel
0manual reconciliation — every completed rental writes back to 1C automatically
2payment paths live — online card and a fast-payment system through one aggregator
10–16 wktypical delivery window for a comparable self-service rental MVP
Why a real-time availability engine over a calendar plugin
The availability model dominates every other choice in a self-service rental product. A calendar-slot plugin — the kind bundled with most booking SaaS — assumes a human confirms each reservation and treats overlap as a soft warning. That breaks the moment two people on the same dock try to take the last free catamaran at the same second. We built MakeWake on a transactional availability engine instead: each rental request acquires a short-lived lock against a specific vessel for a specific window, the availability check and the reservation write happen inside a single database transaction, and conflicting requests fail fast rather than silently overlapping. State is pushed to every open client over a live channel, so a craft that goes on-trip disappears from the catalog within about a second across every phone on the lake.
The same transactional guarantee backs the QR unlock at the hull, so a vessel can never start two trips at once. We compared the engine against the alternatives the team had used before — spreadsheet logs, generic calendar plugins, and a queue-at-the-desk manual process — across the dimensions that actually matter for physical inventory in the US and EU.
| Dimension | Availability engine (MakeWake) | Calendar plugin | Manual desk / spreadsheet |
|---|---|---|---|
| Double-booking prevention | Transactional lock — impossible by design | Soft warning — overlap still possible | Human memory — frequent errors |
| Real-time fleet state | Pushed to every client in ~1 s | Refresh-on-reload only | None — desk knows, riders do not |
| Physical-asset unlock | QR resolves to a specific hull | No asset binding | Attendant hands over keys |
| Trip metering | Server-side meter, tariff-aware | Fixed slots only | Attendant reads a clock |
| Accounting integration | Write-back per completed trip | Manual export | Paper logbook reconciled by hand |
| Scales on a busy weekend | Yes — self-service, no queue | Limited — still needs confirmation | No — queue length is the ceiling |
| Revenue leakage | Metered to the minute | Slot rounding loses minutes | Under-counted by hand |
Platform references: Apple CoreLocation documentation, Android location services reference.
The catalog, the tariff model, and the booking flow
The mobile client opens onto a geolocated catalog: the app asks for location, drops the user onto the nearest lake, and lists the available fleet with a photo, a vessel type, a capacity, and a starting price per hour. A user who declines location can pick a lake manually or jump straight to the QR scanner. Each vessel card opens a detail screen with a tariff selector — a flat first hour, a per-minute rate after that, or an unlimited package — and the control and safety rules for that craft. The booking flow is deliberately short: choose the tariff, choose the payment method, and start. Region and capacity filters keep the list legible when the fleet is large, and the catalog reflects real-time availability so a craft already on the water is never offered.
Because the trip is tied to a physical asset, the flow folds in a mandatory safety step before the meter starts — the user reviews the conduct rules on the water and confirms life jackets are worn, with a one-tap path to call the dock administrator if anything is unclear. That safety gate is not decoration; for a watercraft operator it is the difference between a defensible liability posture and an open one. The whole client surface is delivered as part of our mobile app development practice, with iOS and Android carried in lockstep.
Frictionless sign-in, QR unlock, and the live trip meter
Onboarding had to survive a sunny dock with a phone in one hand. Sign-in is phone-first: enter a number, accept the terms, receive an SMS one-time code, and you are in — with an email path as a fallback. No password, no email-verification round-trip, no account wall between a first-time visitor and the catalog. From there the fastest path to the water is the QR scanner: each hull carries a unique code, scanning it resolves to that specific vessel, checks it is free and the user is eligible, walks through the safety gate, and starts a metered trip bound to that asset. Scanning a craft already on a trip is rejected cleanly because the unlock shares the same transactional reservation that backs the catalog.
The trip meter runs server-side, so a backgrounded or closed app cannot stop the clock. The running cost and elapsed time are mirrored to the client for transparency — the rider always sees what the trip has cost so far — and when the user ends the trip the final amount is captured and a clear summary is shown: trip price, duration, and a prompt to wait while the dock administrator collects the life jackets. The same pattern — scan a physical asset, meter a session, settle automatically — generalizes cleanly to scooters, bikes, lockers, and other self-service inventory, which is why we treat MakeWake as a reference build for self-service mobility across the US and EU.
Payment aggregator, 1C write-back, and data handling
Money moves through a single payment aggregator, which let the operator offer online-card payment and a fast-payment system behind one integration rather than wiring each processor by hand. Card details are tokenised and held by the processor, not by the app: MakeWake stores an opaque card reference so a returning rider can pay with one tap, and the sensitive primary account number never lands in the operator's database. When a trip ends, the captured charge is written back to the operator's 1C accounting backend through agreed data contracts, so finance sees revenue per vessel and per day without anyone re-keying a paper logbook. Because the accounting infrastructure lived on the client side, the contract-first integration was the critical path — we defined the request and response shapes up front so both teams could build in parallel against a stable interface.
On data handling, MakeWake collects only what a rental needs — a phone number for the account, a tokenised payment reference, and trip records tied to that account. Practices are aligned with GDPR for users in the European Union and with CCPA / CPRA for users in California and the broader United States, with consent captured at sign-in and a clear in-app policy. The control plane sits behind our cloud & DevOps practice with infrastructure-as-code and least-privilege access to the payment and accounting integrations.
Compliance posture: GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · CCPA-acknowledged.
Delivery methodology
A five-phase Agile build that took MakeWake from a manual rental desk to a self-service app across iOS, Android, and a contract-first backend.
Availability engine
Transactional reservation core, vessel-level locking, real-time state push to clients, and the QR-to-asset resolution that prevents double-booking and double-start.
Mobile builds
Phone sign-in with SMS code, geolocated catalog, vessel detail and tariffs, mandatory life-jacket safety flow, QR unlock, and the live server-side trip meter on iOS and Android.
Payments & accounting
Payment aggregator integration for online card and fast-payment system, tokenised card storage, and automated write-back of each completed trip into the operator's 1C backend.
Launch & iteration
App Store and Google Play submission across US and EU storefronts, on-dock pilot with the operator, and post-launch tuning of tariffs, filters, and the safety flow.
The operator console — utilization, tariffs, and the dock view
A self-service rental app is only half the product; the other half is the operator-facing console that turns a fleet into a managed business. MakeWake's console gives the operator a live view of every vessel — free, on-trip, or out of service — and the running revenue per craft and per day, replacing the paper logbook that used to be reconciled by hand. Tariffs are configuration, not code: the operator can change the first-hour price, the per-minute rate, or the unlimited package for any vessel class without a release, and the change propagates to the catalog immediately. The dock administrator workflow is built in too — collecting life jackets at end-of-trip, contacting a rider mid-trip, and taking a craft offline for maintenance so it disappears from the catalog. Because every completed rental already writes back to 1C, finance and operations read from the same numbers, and the operator can see at a glance which vessels earn their keep on a busy weekend and which sit idle. The console was built with extensibility in mind: adding a second lake, a new vessel class, a promotional tariff, or a multi-site fleet is a configuration change against the same backend, not a rebuild — the groundwork for scaling the model across the US and EU.
Launching across the United States and the European Union
MakeWake is built as a single English-language product that serves leisure operators across the United States and the European Union without a separate codebase per region. The same app serves riders in California, Florida, Texas, New York, and Washington in the US, and in the Netherlands, Germany, France, Ireland, and Sweden in the EU, with localization and currency handled as configuration rather than forks. Consent is captured at sign-in and is region-aware at the client layer: users in the EU and EEA receive a GDPR-style granular consent screen, and users in California receive a CCPA-style disclosure in the same flow. Data-handling practices are aligned with GDPR for European Union users and with the US state-privacy patchwork — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas), and Oregon CPA. Because MakeWake collects only the phone number, a tokenised payment reference, and trip records, regional compliance reduces to honest disclosure and a clean deletion path rather than per-jurisdiction data segregation.
For payments, the aggregator pattern lets a US or EU operator swap in the local card networks and fast-payment rails appropriate to their market behind the same in-app checkout, and the tokenised-card model keeps the sensitive account number out of the operator's systems on both sides of the Atlantic. The matching backend that resolves a QR scan to a vessel and meters the trip runs stateless workers that can be pinned to EU or US regions independently for future data-residency commitments. The engineering team behind the build runs a CET workday with East-Coast US overlap (9 AM–1 PM ET) for stand-ups, store-review choreography, and incident response — the timezone that lets a US operator and an EU engineering team share four hours of live overlap every day. The result is a self-service rental product that is genuinely deployable across the US and EU, not a single-market app retrofitted after the fact.
Tech stack and roadmap
Kotlin
Jetpack Compose
Swift
SwiftUI
CoreLocation
Android Location
QR scanning
PHP
PostgreSQL
Redis
WebSockets
Payment aggregator
1C integration
SMS OTP
Docker
Terraform
Prometheus
Grafana
The active custom software development roadmap for MakeWake includes a multi-site fleet view for operators running more than one lake or marina, a promotions and loyalty layer to convert the repeat-booking lift into a membership tier, and an offline-tolerant QR unlock for docks with patchy connectivity. On the operations side we are extending the console with utilization forecasting and maintenance scheduling, and scaffolding a future data-residency split so EU and US fleets can run on regionally pinned infrastructure under the cloud & DevOps roadmap. The self-service unlock-and-meter pattern is general enough that the same backend can carry scooters, bikes, and lockers, which keeps the door open to a broader self-service mobility platform for US and EU operators.
Build a self-service rental app like this — talk to us
If you are planning a self-service rental, marina, or leisure-mobility product — anything where a rider unlocks a physical asset, a meter runs, and money has to settle cleanly into your accounting backend across the US and EU — we have shipped this stack end-to-end and can compress the build timeline meaningfully. You can read more about the product on the live site at yusmpgroup.ru, and the engineering team behind it sits inside YuSMP Group. We work Agile, fixed-scope for well-defined MVPs and on dedicated development teams for ongoing delivery, with a CET workday and a guaranteed East-Coast US overlap (9 AM–1 PM ET) window for stand-ups, demos, and incident response.
Frequently asked questions
How much does it cost to build a self-service boat or watercraft rental app?
A focused rental MVP with phone sign-in, a vessel catalog, real-time availability, QR unlock, and automated time-based billing typically costs $90k–$180k. Adding multi-method payment, an accounting integration such as 1C or QuickBooks, a safety and life-jacket flow, geolocated fleet discovery, and an operator console brings a full product to $200k–$420k. The dominant cost drivers are the payment and accounting integrations, the availability engine that prevents double-booking, and the operational tooling staff use on the dock every day.
How do you prevent double-booking in a rental availability engine?
Double-booking is prevented at the data layer, not the UI. Each rental request acquires a short-lived lock against a specific vessel for a specific window, the availability check and the reservation write happen in a single database transaction, and conflicting requests fail fast rather than silently overlapping. Real-time state is pushed to every open client so a vessel that goes on-trip disappears from the catalog within a second. The same transactional guarantee backs the QR-unlock flow so a craft cannot start two trips at once.
What does automated time-based billing for a rental app involve?
Time-based billing meters the trip from unlock to end-of-trip and applies a tariff — a flat first hour, a per-minute rate after that, or an unlimited package. The meter runs server-side so a closed or backgrounded app cannot stop the clock, the running cost is mirrored to the client for transparency, and the final amount is captured through a payment aggregator when the trip ends. Every charge is written back to the accounting system so finance sees revenue without manual reconciliation.
How does a QR-unlock flow work for physical rental assets?
Each vessel carries a unique QR code. Scanning it in the app resolves to a specific asset, checks that the asset is free and the user is eligible, walks the user through the mandatory safety and life-jacket step, then starts a metered trip tied to that asset. The unlock is gated by the same transactional reservation that backs catalog booking, so scanning a craft that is already on a trip is rejected cleanly. The pattern generalizes to scooters, bikes, lockers, and other self-service inventory.
How long does it take to ship a rental booking app on iOS and Android?
A focused MVP with sign-in, a vessel catalog, real-time availability, QR unlock, and one payment method typically takes 10–16 weeks. Adding multi-method payment, an accounting integration, a safety flow, geolocated discovery, and an operator-facing console adds 6–10 weeks. The integration work — the payment aggregator and the client's accounting backend — is usually the critical path, especially when that infrastructure lives on the client side and has to be reached through agreed data contracts.
Related cases
More mobility & consumer platform builds
Mobility · Rental
Light Rent
Self-service vehicle rental with booking, availability, and automated billing across US & EU operators.
View case → Mobility · MicromobilityScooter Sharing
QR-unlock micromobility platform with geolocated fleet, metered trips, and a rider and operator app.
View case → Travel · ConsumerMove2Armenia
Consumer travel and relocation platform with services discovery and a native mobile experience.
View case →Related services
Mobile App Development
Native iOS, Android, and cross-platform apps with store-ready release pipelines.
Explore mobile app development →
Custom Software Development
Custom platforms engineered to your business model, scaling cleanly from MVP to millions of users.
Explore custom software development →
Cloud & DevOps
Infrastructure-as-code, CI/CD, and observability for products that have to stay up across US & EU.
Explore cloud & DevOps →