How to Make an App Like Enterprise CarShare

Building a corporate car-sharing platform is a non-trivial engineering problem. Fleet state, booking concurrency, telematics integration, and billing reconciliation all need to work together in real time. This post walks through the architecture decisions you'll actually face.

What Does an Enterprise CarShare-Style Platform Actually Do?

Enterprise CarShare is a B2B fleet-sharing service. Companies subscribe, employees book vehicles through a web or mobile interface, the vehicle unlocks via a connected hardware module, and the trip is billed to a cost centre. That sounds straightforward. The complexity lives in the edges.

• Fleet availability is real-time and location-aware. A vehicle that was available two seconds ago may already be booked.
• Vehicles need to be physically accessed, which means integrating with telematics hardware or OEM APIs, not just sending a push notification.
• Corporate billing splits across cost centres, departments, and approval workflows. This is not a simple payment flow.
• Compliance requirements vary by region: driver licence verification, insurance validation, and duty-of-care obligations for fleet managers.

Core Architecture: How Do You Model Fleet State?

This is where most teams underestimate the problem. Fleet state is not a simple availability flag.

The Booking State Machine

A vehicle moves through states: available, reserved, active, returning, maintenance, unavailable. Each transition has a trigger (user action, telematics event, or scheduled job) and a set of side effects (notifications, billing events, access grants).

Use an event-sourced model rather than a mutable state table. Each state change is an immutable event appended to a log. The current state is derived by replaying the log. This makes debugging a live booking dispute tractable. PostgreSQL with the pg_eventstore pattern works well here, though purpose-built solutions like EventStoreDB are worth evaluating if your event volume exceeds a few thousand per second.

Concurrency and Double-Booking

Booking a vehicle is a classic optimistic-locking problem. Two users can simultaneously read the same available record, both attempt to write a reservation, and without a guard, both succeed.

The standard approach is a serialisable transaction with a row-level lock on the vehicle record at reservation time. In PostgreSQL, SELECT FOR UPDATE inside a transaction handles this. If you're running a distributed database like CockroachDB or Spanner, you need to account for distributed transaction latency, which adds 20–80 ms per write depending on region placement. For a booking action, that's acceptable. For a real-time map update, it is not — those reads should bypass the transactional path entirely.

Geospatial Queries

Fleet discovery is a geospatial query: "show me all available vehicles within 1 km of this coordinate." PostGIS with a GiST index on a geography column handles this at scale. For 50,000 vehicle records, a radius search with a bounding box pre-filter runs in under 10 ms on modest hardware. Beyond that scale, you may want to shard by geographic zone.

How Does Vehicle Access Actually Work?

This is the part that separates a car-sharing app from a standard booking app. You need a hardware integration.

Telematics and OEM APIs

Most enterprise fleets use a telematics device: a hardware module fitted to the OBD-II port or wired into the CAN bus. Vendors like Webfleet, Geotab, and Zubie expose REST or MQTT APIs for lock/unlock commands, ignition state, GPS position, and fuel level.

OEM APIs (Ford, GM, Stellantis) are available through programs like Ford Developer or GM's API portal, but they're slower to onboard, more restrictive on vehicle year/model coverage, and frequently change authentication flows. For a mixed fleet, a third-party telematics vendor is usually more practical.

The unlock flow is asynchronous. Your backend sends a command, the telematics device acknowledges receipt, and the vehicle responds when the command is executed, which may take 2–15 seconds over a cellular connection. Your mobile app needs to handle this with a polling or webhook callback pattern, not a synchronous HTTP response.

Keyless Entry as a Fallback

Some deployments use Bluetooth Low Energy (BLE) as a secondary access channel. The mobile app communicates directly with a BLE module in the vehicle when the user is within range (typically 10 m). This reduces latency to under one second and works without a cellular signal. The trade-off is increased mobile SDK complexity and a separate firmware update path for the BLE module.

Billing, Cost Centres, and Approval Workflows

Corporate billing is more complex than consumer billing. You're not charging a single card; you're allocating costs across an org structure.

Data Model

You need a hierarchy: Organisation → Department → Cost Centre → User. A trip is tagged to a cost centre at booking time. The billing engine aggregates trips by cost centre per billing cycle and generates itemised invoices.

Rate cards vary: some organisations pay per minute, some per kilometre, some on a hybrid model. Store rate cards as versioned records so that historical trips can always be repriced against the rate card that was active at the time.

Approval Workflows

Some bookings require manager approval before the vehicle is accessible. This adds a state to the booking machine (pending_approval) and requires an async notification path: email, Slack webhook, or an in-app notification, depending on what the customer has configured. Build this as a configurable step rather than hard-coding any specific integration.

Payments and Reconciliation

If you're handling real-money transactions rather than pure cost-centre allocation, Stripe is the most practical choice for a new build. Their PaymentIntent API handles 3D Secure natively, and their Connect product handles multi-party payouts if you're building a marketplace variant.

For enterprise invoicing, you will likely need to integrate with an ERP: SAP, Oracle NetSuite, or Microsoft Dynamics. These integrations are where projects often stall. Allocate more time than you think you need. A SAP integration via IDoc or BAPI takes longer to test than the core booking flow.

What Should You Build vs. Buy?

Component	Build	Buy
Booking and state machine	Yes	Rarely fits off-the-shelf
Telematics integration	Partial (adapter layer)	Use vendor SDK/API
Geospatial search	PostGIS	Adequate for most scales
Payments	No	Stripe or Adyen
Driver licence verification	No	Onfido, Persona, or similar
Push notifications	No	Firebase Cloud Messaging
Maps and routing	No	Google Maps Platform or Mapbox

The booking core and the cost-centre billing logic are your proprietary value. Everything else has a mature vendor solution. Treat the telematics layer as an adapter: write an interface, implement one vendor behind it, and swap later without rewriting the booking engine.

Conclusion

The hardest parts of this build are fleet state consistency, telematics latency, and corporate billing complexity. None of these are unsolvable, but all three require deliberate design upfront. If you start with a mutable availability flag and a single billing model, you will refactor both within six months.

Start with the state machine and the data model. Get those right and the rest follows.

---

FAQ

How long does it take to build a platform like Enterprise CarShare? A functional MVP covering booking, vehicle access via telematics, and basic billing typically takes 4–6 months with a team of 4–6 engineers. Corporate approval workflows, ERP integration, and multi-region fleet management add another 2–4 months depending on the complexity of the customer's org structure.

What tech stack is best for a car-sharing platform? There is no single best stack. A common choice is Node.js or Go for the booking API (low latency, good async support), PostgreSQL with PostGIS for fleet and geospatial data, React Native for iOS and Android apps, and Stripe for payments. The telematics layer is vendor-dependent and sits behind an adapter interface.

How do you prevent double-bookings at scale? Use serialisable transactions with row-level locking on the vehicle record at reservation time. In PostgreSQL, SELECT FOR UPDATE inside a BEGIN/COMMIT block is the standard approach. In a distributed database, you need explicit distributed transaction support. Optimistic locking with a version column is faster but requires retry logic in the application layer.

Do you need a hardware device in every vehicle? For remote lock/unlock and real-time GPS, yes, a telematics device or OEM API is required. Some low-tech deployments use a key lockbox at a fixed location and skip remote access entirely, but this limits the user experience significantly and removes the real-time fleet visibility that makes the product valuable to fleet managers.

What are the biggest integration risks? ERP billing integration (SAP, NetSuite) and telematics hardware onboarding are consistently the longest-tail risks. Both involve external system owners, inconsistent documentation, and slow test environments. Budget time for these explicitly rather than treating them as straightforward API integrations.

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