How to Make an App Like Hertz 24/7

A practical breakdown of the architecture, integrations, and product decisions that go into building a self-service vehicle rental platform — from telematics to payment rails.

What Does Hertz 24/7 Actually Do Under the Hood?

Hertz 24/7 is a keyless, self-service car rental system. Users book a vehicle via app, walk up to the car, unlock it through Bluetooth or a relay command sent over cellular, drive, return it, and the session ends automatically. No counter, no key handoff, no human in the loop.

The core technical components are:

• A mobile app (iOS and Android) handling booking, identity verification, and vehicle access
• A telematics device installed in each vehicle that receives unlock/lock commands and reports location, ignition state, and mileage
• A backend that manages reservations, real-time vehicle state, billing, and fleet operations
• Third-party integrations for KYC, payment processing, insurance, and roadside assistance

Each of these is straightforward in isolation. The difficulty is in the timing and reliability requirements when they work together.

What Tech Stack Should You Build On?

There is no single correct answer, but the constraints narrow the choices quickly.

Mobile

The vehicle access flow has to work with degraded connectivity. A user standing in a car park at 11 PM with one bar of signal cannot be told to try again later. That means the app needs to cache the booking token locally and be able to initiate an unlock attempt offline, queueing the command if needed.

React Native works here if your team already knows it. Flutter gives you more control over Bluetooth low energy (BLE) interactions, which matter if you are integrating directly with a hardware module rather than going through a cloud relay. If your telematics vendor provides a BLE SDK, check which platforms it officially supports before committing to a cross-platform framework.

Backend

A monolith is fine to start. The reservation engine, vehicle state machine, and billing service do not need to be separate microservices on day one. Where you will want separation early is between anything time-critical (lock/unlock commands, real-time location polling) and anything that can tolerate latency (invoicing, analytics, CRM sync).

A practical split:

Service	Latency tolerance	Suggested approach
Vehicle command dispatch	< 2 seconds	Dedicated lightweight service, Redis queue
Reservation management	< 500 ms	Standard REST API, PostgreSQL
Billing and invoicing	Minutes	Async worker, idempotent job queue
Fleet ops dashboard	Seconds	Read replica, separate query layer

Node.js or Go are common choices for the command dispatch path. PostgreSQL handles the reservation and billing data well. If you expect significant fleet size (500+ vehicles), add a time-series store like TimescaleDB for telemetry.

Telematics

This is where most teams underestimate complexity. The telematics device in the car is the physical enforcement point. If it does not receive the unlock command, the user cannot get in.

Most commercial telematics units communicate over 4G LTE and have a SIM card managed by the hardware vendor. The unlock flow typically looks like this:

1. App sends unlock request to your backend
2. Backend validates the session (right user, right vehicle, right time window)
3. Backend sends command to telematics platform API
4. Telematics platform pushes command to device over cellular
5. Device actuates the door lock relay
6. Device sends acknowledgement back

Steps 3 to 6 can take anywhere from 800 milliseconds to 8 seconds depending on network conditions and the hardware vendor. Build your app UI around this. Show a progress state. Do not let the user tap "unlock" repeatedly.

Vendors worth evaluating: Ruptela, Teltonika, Geotab, and Webfleet all have developer APIs. Evaluate them on command latency SLAs, device availability in your target market, and quality of their webhook/event stream for real-time state updates.

How Do You Handle Identity Verification and Insurance?

You cannot hand someone the keys to a car, even digitally, without knowing who they are. At minimum you need:

• Government-issued ID verification (passport or driving licence)
• Driving licence validation (check it is current and covers the vehicle category)
• A check against a fraud or sanctions list

In the UK and EU, Onfido and Jumio are the standard integrations. In India, Digilocker APIs allow direct verification against the UIDAI database. Turnaround for automated checks is typically under 30 seconds. Manual review queues for edge cases will add hours, so design a flow that allows partial access (browse, save payment method) while verification is pending.

Insurance is more market-specific. In the UK, telematics-based per-minute insurance is available through providers like By Miles or Zego. In most markets, you are looking at a fleet policy underwritten per vehicle, with the rental session data used for claims rather than pricing. Work out your insurance model before you finalise the telematics spec, because the data your insurer needs (trip start/end timestamps, mileage, location) should be captured at the device level, not reconstructed from app logs.

Pricing, Payments, and the Billing Edge Cases

Stripe handles the standard flows well: card authorisation at booking, capture at session end, refund if the user cancels within the window. Use Stripe's payment intents API rather than charges directly. It gives you 3DS2 compliance out of the box and better dispute handling.

The edge cases are where it gets interesting:

• Session overruns: User does not return the car on time. You need to detect this via telematics (ignition still on, or vehicle not at return location), notify the user, and switch to an overage rate automatically.
• Damage claims: You need a pre- and post-rental photo capture flow in the app. Store images with timestamps and GPS coordinates. This is your evidence trail for any chargeback dispute.
• Failed end-of-session charge: Card declines after the rental. You need a dunning sequence and the ability to hold a deposit pre-authorisation.

Pre-authorise a damage deposit (typically £150 to £500 depending on vehicle class) at booking. Release it within 7 days of session close. Communicate this clearly in the app. It is one of the most common sources of user complaints in car-sharing products.

Fleet Operations: The Part No One Talks About

The app is what users see. The fleet ops tooling is what keeps the business running.

Your operations team needs:

• A live map showing every vehicle's location, fuel level, battery state (for EVs), and lock status
• Alerts for vehicles that have not moved in over 48 hours (could indicate a breakdown or abandonment)
• The ability to remotely lock a vehicle if a rental goes wrong
• Maintenance scheduling tied to odometer readings pulled from telematics
• A damage report workflow linked to individual reservations

Build this as an internal web dashboard, not a mobile app. Operations staff work at desks. A React-based SPA backed by your read replica is sufficient. Role-based access control matters here: a field technician should not have the same permissions as a fleet manager.

If you are starting with fewer than 100 vehicles, a well-structured admin panel (even something like Retool or a custom-built internal tool) gets you to market faster than building a bespoke dashboard from scratch.

Conclusion

The architecture for a Hertz 24/7-style platform is not technically exotic. The complexity is in the reliability requirements, the integration surface area, and the operational tooling that runs alongside the consumer-facing app.

Start with a clear telematics vendor decision, because it shapes your unlock flow, your insurance data model, and your ops dashboard. Get KYC and payments specified early. Build the fleet operations tooling in parallel with the consumer app, not after it.

If you are at the stage of scoping this out and want a second opinion on architecture or vendor choices, Sodio has built in this space and we are happy to talk through what we have seen work.

---

FAQ

How long does it take to build a car-sharing app like Hertz 24/7? A production-ready MVP with booking, telematics integration, KYC, and payments typically takes 5 to 8 months with a team of 4 to 6 engineers. The timeline is usually gated by telematics hardware procurement and insurance setup, not the software build itself.

What is the difference between a telematics relay and a BLE-based unlock? A cellular relay sends the unlock command from your server through the telematics device. BLE unlocks happen directly between the user's phone and a module in the car. BLE is faster and works without mobile data, but requires the user to be within 10 metres and depends on Bluetooth being enabled on their device.

Do you need a separate app for fleet managers? No, a web dashboard is sufficient for most fleet operations. Mobile access is useful for field technicians doing damage checks or vehicle relocations, but a responsive web app handles that without a separate native build.

How do you handle a vehicle that goes offline mid-rental? The telematics device should log all trip data locally and sync when connectivity is restored. The user's session remains active based on the app-side token. For lock/unlock, you need a fallback: either a PIN pad on the vehicle or a customer support override. Design for it before launch.

What insurance model works best for on-demand car rental? It depends on your market and fleet size. Per-trip insurance (priced per minute or kilometre) is better for high-utilisation fleets and reduces cost for short rentals. A fleet policy is simpler to administer and works well when utilisation is harder to predict. Talk to your broker before finalising the telematics data spec, since the data fields your insurer needs should be captured from day one.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.