Documentation
A working tour of how Ridenet is put together. Detailed integration guides are on the way — for now, here's the shape.
Platform overview
Ridenet is four moving parts: a Next.js operator dashboard, an Expo rider app for iOS and Android, a Convex realtime backend that holds vehicle and trip state, and a Rust TCP gateway that talks to the smart locks over LTE. Operators and riders see live state on every screen because every read is a subscription, not a poll.
Data flow
When a lock powers on it dials the Ridenet gateway over LTE. The gateway parses the lock's proprietary protocol and writes telemetry (location, lock state, trips) into Convex. The operator dashboard and rider app subscribe to the same data, so unlock acks, ride starts, and trip ends propagate in under a second. Outbound commands (unlock, lock, ring) round-trip the same way.
White-label tenants
Each operator can run a fully white-labeled rider app and marketing site against the same shared backend. White-label tenants get their own domain, colors, copy, and Stripe Connect account — but inherit every platform update we ship to the core stack.
Roles & permissions
Capabilities (rentals:read, vehicles:write, etc.) are configured per-role in one file, then enforced server-side at every Convex mutation. Operator staff get a different scope than fleet managers, who get a different scope than admins. Riders authenticate with a separate flow and only see their own bookings.
More guides coming soon
Lock pairing walkthrough, Stripe Connect setup, white-label theming, webhook payloads, and more. Want a specific topic prioritized?
Request a guide