Parking Platform Development: Booking, Listing and Operations in One System
A complete parking platform built end to end - a Flutter app for drivers, a Next.js web portal where space owners list and price their lots, and an admin console that runs the whole operation from one screen.
3 Surfaces
App, portal, console
QR Check-In
Scan to open the session
3 Pay Rails
Card, Apple Pay, Google Pay
A Parking Business With Spaces to Sell and No System to Sell Them Through
Our client works with parking inventory across US properties — private lots, building basements, spaces behind retail units. The supply was real and mostly sitting idle. What they didn't have was software: no way for a driver to find a space and pay for it before arriving, no way for a property owner to list a lot without a phone call, and no single place where anyone could see what was actually happening across the estate. It ran on attendants, spreadsheets and trust.
The gaps compounded. Drivers circled because availability was invisible until arrival. Payment happened at the barrier, so every location needed someone on shift. Nothing recorded when a car entered or left, which made overstay charges unenforceable. Owners who wanted to put a lot on the platform waited on a member of staff to key it in. And when the client wanted to know how a given property performed last month, someone had to go and assemble the answer by hand.
They asked Akoode to build the product, not a piece of it. We delivered three connected surfaces on one shared API: a Flutter app for drivers covering discovery, booking, Stripe checkout, QR check-in and live session control; a Next.js web app that doubles as a self-serve portal for space owners and a desktop booking flow for drivers; and an admin console for approvals, oversight, content, support and refunds. The mobile app alone runs to 188 source files across ten feature modules, and shipped to the Play Store and TestFlight with signed release tooling committed beside the code.
3
Connected surfaces
Driver mobile app, owner and driver web app, and admin console — all on one API and one data model.
4
Sign-in paths
Email and password, phone OTP, Google, and Apple, all resolving into one session model.
3
Payment methods
Saved cards, Apple Pay and Google Pay through a single Stripe integration.
0
Credentials in plain storage
Access and refresh tokens sit in Keychain and Keystore, never in preferences.
Project Info
Client
Confidential, United States
Industry
Mobility & Smart Parking
Use Case
Parking marketplace — discovery, booking, access control and operator management
Solution
Flutter app for iOS and Android, Next.js web app and admin panel, Node and MongoDB backend
Engagement
Fixed Cost
The Spaces Existed. Everything Between the Driver, the Owner and the Space Was Manual.
No single failure here was fatal on its own. Stacked together, they were. A driver who can't check availability arrives at a full lot. A driver who can't pay in advance queues at the barrier. A lot with no arrival record can't settle a dispute. An owner who can't list a space themselves waits on staff. And a business with no console can't see any of it happening. Every gap made the next one more expensive.
Availability Was Guesswork
Drivers had no way to see which nearby lots had room for the hours they actually needed. They drove over and found out.
Payment Happened at the Barrier
Collecting at the gate meant cash, card readers and someone on shift. It capped how many locations the business could realistically run.
No Record, No Flexibility
Nothing logged when a car entered or left, so overstay charges were unenforceable. And a booking couldn't be extended — a driver running late either overstayed or lost the space.
The Back Office Was a Person
Listing a lot, changing a price, checking last month's numbers, issuing a refund — all of it went through staff and spreadsheets. Nothing scaled past the size of the team.
Parking isn't a booking problem. It's a booking problem that ends at a physical barrier and starts in someone's back office — and software that only covers checkout solves the easy third.
What the Build Had to Deliver
The client wasn't asking for a listings app with a payment button bolted on. They needed the whole operation to run on software: the driver's journey from search to departure, the owner's ability to put inventory on the platform without help, and their own ability to see and control all of it. Three audiences, one system, no manual bridge between them.
One Platform, Three Front Doors
Drivers, space owners and administrators each needed a surface built for how they work — a phone, a browser, a console. All three had to read and write the same inventory through one API, so a price changed in the portal is the price the app quotes seconds later.
Search That Reflects Real Availability
Nearby and recommended lots had to be queried against the driver's actual location and their chosen arrival and exit times, not just proximity. A lot that's full for the requested window should never look bookable.
Priced, Paid and Checked In
The driver picks a window, sees the exact cost for it, and pays before leaving — with Apple Pay and Google Pay treated as first-class, not a fallback. Arriving at the bay and scanning its QR code opens the session against that specific booking, turning arrival time into data rather than testimony.
Owners Who Onboard Themselves
A space owner had to be able to register, list a property, upload photos, set pricing and availability, generate the QR code for each bay, and watch bookings and earnings arrive — without a single call to the client's team.
Admins Who Can See and Fix Anything
One console covering owner and lot approvals, every booking and payment on the platform, content and notification campaigns, and the support actions that real operations need — refunds, manual checkout, dispute resolution.
One System, Built in the Order the Business Runs
We built this as a single platform with a shared data model, a shared API and a shared session — not three products that later learned to talk. Inventory has one owner: the backend. Neither the app nor the portal decides what's available or what it costs, which is what keeps three clients from disagreeing about the same parking space.
Foundation and Shared API
A Node and Express backend over MongoDB, modelling owners, properties, slots, availability windows, bookings, payments and ratings once. Every surface consumes the same endpoints, so business rules — pricing, cancellation policy, availability — live in exactly one place and can't drift between clients.
Identity and Session
2. Identity and Session
Four sign-in routes on mobile — email with OTP verification, phone with OTP, Google and Apple — plus role-aware access on the web separating drivers, owners and administrators. Tokens go straight to secure storage on device, and a shared refresher keeps sessions alive through rotation without ever bouncing a signed-in user to the login screen.
The Driver App
Google Places autocomplete for destination search, geolocation for the driver's position, and nearby and recommended lot queries filtered by date, time window and distance. Google Maps renders results with custom light and dark styles, the Directions API draws a decoded route to the space, and the booking flow runs availability check, server-side pricing, Stripe checkout, QR check-in, a live countdown, paid extension and automatic checkout.
The Web App — Owner Portal and Desktop Booking
A Next.js application serving two audiences from one codebase. Owners register properties, upload photos, set rates and availability, generate bay QR codes, and track bookings and earnings from a dashboard. Drivers who'd rather book on a laptop get the same search, pricing and Stripe checkout as the app, hitting the same endpoints.
Admin Console, Notifications and Release
An admin panel for owner and lot approvals, platform-wide booking and payment visibility, CMS and notification campaigns, and support tooling for refunds and manual checkout. Alongside it, Firebase Messaging with a high-importance Android channel and per-user notification settings, dark mode across the app, offline handling, and shell scripts that produce a signed Play Store bundle and a TestFlight-ready IPA.
What Each Audience Actually Uses
Highlight 01
Map Search With Availability Baked In
Destination search runs through Google Places autocomplete, and nearby and recommended lots come back scored against the driver's position and requested window. Tapping a pin slides up a detail drawer with photos, price and distance before the driver commits to anything.
- Places autocomplete with persisted recent searches
- Filters for date range, arrival time, exit time and radius
- Custom light and dark map styling that follows the app theme
Highlight 02
Priced for the Window, Paid With a Wallet
Before a booking exists, the platform checks the slot is genuinely free for those hours and prices that exact window server-side — so the number on the confirm screen is the number charged. One Stripe sheet then covers saved cards, Apple Pay and Google Pay, and payment is only trusted once the backend has verified the intent.
- Availability checked, then priced, then booked — in that order
- Native wallet buttons on both platforms, 3D Secure returning via a registered URL scheme
- Server-side verification before any booking unlocks
Highlight 03
QR Check-In and a Session You Can Extend
The driver scans the code posted at the bay; the app resolves owner and slot from the payload and opens the session against their booking. From there a live countdown tracks elapsed against booked time, and extending is two taps — the platform re-checks availability, prices the extra time, takes payment and confirms, all without ending the session.
- Two QR payload formats supported, keys case-insensitive
- Automatic checkout the moment the window closes
- Cancellation respects the operator's grace period and lead-time policy
Highlight 04
The Owner Portal — List, Price, Get Paid
Space owners register and put a property on the platform themselves — photos, address, bay count, rates and availability windows — then generate the QR code each bay needs for check-in. A dashboard shows incoming bookings, current occupancy and earnings without anyone at the client having to be involved.
- Self-serve property and slot setup with photo upload
- Per-slot pricing and availability windows
- Bay QR generation, plus live booking and earnings views
Highlight 05
The Admin Console — Oversight and Support in One Place
Administrators approve owners and listings, search every booking and payment on the platform, and handle the situations software alone can't — refunds, stuck sessions, disputes. Content and notification campaigns are managed from the same console, so a message to drivers doesn't need a deployment.
- Owner and listing approval queues
- Platform-wide bookings, payments and analytics
- CMS, push campaigns and support actions including refunds and manual checkout
Chosen for Live Location, Live Money and Three Clients That Must Agree
This platform spends its whole life talking to something outside itself — the device's GPS, Google's map and directions services, Stripe's payment infrastructure, Firebase's push delivery — while three different clients read and write the same parking inventory. The stack was picked for exactly that: one Flutter codebase rendering native on both mobile platforms, a Next.js application serving owners and desktop drivers, and a Node API over MongoDB holding the single version of what's available and what it costs.
Mobile Application
A single Flutter codebase producing native iOS and Android builds, with Riverpod holding session, booking and theme state so every screen reads the same truth. Google Maps, Places and Directions power discovery and routing.
Web App & Admin Panel
Next.js serves both the owner portal and the desktop driver flow with server-rendered pages where they help and client interactivity where they're needed, plus the admin console behind role-aware access.
Backend, Data & Integrations
A Node and Express API over MongoDB owns inventory, pricing and booking rules for all three surfaces. Stripe handles cards and both native wallets; Firebase Messaging delivers session notifications across platforms.
The Parts That Took the Longest Weren't the Screens
Individually, every module here is well-trodden ground. The difficulty lived in the seams - what happens when six requests get a 401 in the same second, what happens when a payment sheet succeeds but verification hasn't run, what happens when the phone was asleep for two hours during an active session, and what happens when the same parking bay is being looked at from an app, a browser and an admin console at once.
Concurrent 401s Were Signing Users Out
The backend kills the old refresh token on rotation, so several requests expiring at once each refreshed alone — the losers hit a dead token and got signed out.
Our Approach
One shared refresher caches the in-flight request, so concurrent 401s collapse into a single refresh. It runs on a bare client, so it can't recurse.
Money and Inventory Have to Agree
Between booking, the payment sheet and Stripe's response, money and inventory can diverge - a dismissed sheet, a 3D Secure redirect, a network drop after the charge.
Our Approach
No client decides availability, price or payment. Both surfaces check, price and book against the API, then hand the intent ID back for server-side verification before confirming.
A Timer That Stays Honest While the Phone Sleeps
A session runs for hours in the background. A countdown that decrements in memory drifts across suspension and returns wrong - and it decides when the driver is auto-checked-out.
Our Approach
Progress is recomputed from absolute timestamps every tick, never carried forward, so the first tick after resume is right. Checkout then fires once, guarded against re-renders.
Push That Lands on Both Platforms and Opens the Right Thing
iOS returns a null FCM token until APNs registration completes, breaking notifications for new installs. And a completed-session push must open the right booking's rating sheet, alive or dead
Our Approach
Token setup retries APNs before requesting the FCM token, refusing a broken one. All three delivery paths feed one stream that refetches the booking and shows the rating sheet.
From an Attended Barrier and a Spreadsheet to a Platform That Runs Itself
Before this build, every parked car needed a person somewhere in the loop — to confirm a space, take money, settle an argument about arrival time, or key a new lot into a spreadsheet. The platform removes those touchpoints and replaces each one with a record. Here's what the client had, what we built, and how the operation works now.
Drive and Hope
No way to check whether a lot had room for the hours needed. Availability was discovered on arrival.
Pay at the Gate
Money changed hands at the barrier, which meant queues, cash handling and a staffed shift per location.
Arrival Was Unrecorded
Nothing logged when a car entered or left, so overstay charges were unenforceable and usually written off.
Onboarding Meant Paperwork
A new lot, a price change or a monthly figure all went through staff, and the numbers lived in spreadsheets nobody fully trusted.
Window-Aware Search
Nearby and recommended lots queried against location, date, time and radius, with a detail drawer before the driver commits.
In-App and In-Browser Checkout
Card, Apple Pay and Google Pay through Stripe on mobile and web, verified against the backend before confirmation.
QR Check-In and Live Sessions
Scanning the bay code opens the session against the real booking, then a timestamped countdown handles extension and checkout.
Owner Portal and Admin Console
Self-serve listing, pricing and QR generation for owners; approvals, platform analytics, CMS and support tooling for admins.
Booked Before Departure
The driver knows the space exists and the price is fixed before the engine starts. No circling.
Unattended Entry
Payment and access both happen in software, so a location no longer needs someone on shift to operate it.
Disputes Have Evidence
Every session carries a check-in and checkout record, so overstay questions are settled by data instead of argument.
Supply Grows Without Headcount
Owners add their own lots and overstays convert into paid extensions — both revenue paths now scale without adding staff.
3Surfaces on one API
App, owner portal and admin console share a single data model, so inventory and pricing can't drift between them.
100%Payments verified server-side
No booking or extension is treated as paid until the backend confirms the payment intent.
ZeroTokens in plain storage
Access and refresh tokens live only in the iOS Keychain and Android Keystore.
Where This Architecture Transfers
Strip out the word "parking" and a pattern is left: a marketplace that sells time windows on physical resources, takes payment before arrival, verifies presence with a scan, lets the customer extend without talking to anyone, and gives suppliers a self-serve portal and operators a console. That shape shows up across a lot of industries.
EV Charging Networks
Reserve a charger for a window, pay up front, scan to unlock the connector, and extend if the battery needs longer. Site hosts manage their own chargers and tariffs from a portal.
Storage and Locker Rental
Short-term unit booking with QR-based access at the door and a running session the customer can extend from their phone, while facility owners list and price units themselves.
Coworking and Meeting Rooms
The same discovery-to-access flow for desks and rooms — priced by the hour, unlocked by a scan, extendable when a meeting overruns, with space operators managing their own inventory.
Fleet and Loading Bay Slots
Delivery operators booking dock time in advance, with scan-in proving arrival and giving the site a clean, disputable-proof record of dwell time.
Sports Courts and Studios
Court and studio bookings where availability is genuinely time-boxed and customers need unattended access outside staffed hours.
Event and Venue Parking
Pre-sold parking for stadiums and festivals, where the volume makes attended payment impossible and QR entry is the only workable gate.
Why Teams Bring Platforms Like This to Us
Anyone can assemble an app from packages or stand up a dashboard. What decides whether a platform like this survives real users is how it behaves at the edges — expired tokens, dropped connections, a payment sheet dismissed at the wrong moment, a phone asleep for three hours, two clients looking at the same bay. That's the work we take seriously.
One Team Across Mobile, Web and Backend
The Flutter app, the Next.js portal and the Node API were built by the same team against one data model, which is why a price set in the owner portal is the price the app quotes. Nobody spent a sprint reconciling two versions of a parking slot.
Security Treated as Default, Not a Phase
Tokens go to Keychain and Keystore, refresh is single-flight and non-recursive, and request logging is compiled out of release builds. Availability, pricing and payment confirmation are never client-side decisions.
Payment Integrations We've Actually Debugged
Apple Pay merchant identifiers, 3D Secure redirect schemes, and the gap between "the sheet closed" and "the money moved" — this build handles the parts that only surface once real cards are involved.
Delivered to the Stores, Not to a Repo
Signed Play Store bundles and TestFlight archives with build scripts committed alongside the code, plus a deployed web app and admin console. The client's team can cut a release without us in the room.