PARKING GENIE

Trust, verified. — A zero-trust valet platform, live in production.

The Signature Design: A Handshake That Runs Both Ways

The hardest problem in valet isn't logistics — it's that trust must be proven twice, in opposite directions. At pickup, the customer risks handing keys to an impostor. At return, the runner does.

One verification scheme can't cover both. So the handshake inverts.

At pickup, the code appears on the customer's phone and the runner must type it — proving the runner is standing with the real customer. At return, a brand-new code appears on the runner's screen, and only the customer can enter it into their authenticated account — proving the keys go home to their actual owner.

Each party verifies the other exactly once. Verification always flows toward whoever bears the risk.

Built solo. Deployed on Railway. Real SMS auth. Tested by real users.

What is Parking Genie?

Parking Genie is on-demand valet for stadiums and events, rebuilt so that trust is verified instead of assumed. A customer arriving at a packed venue requests a "runner" through the app. The runner arrives in minutes, takes the keys, parks the car, and returns it on demand — but every key handoff, in both directions, is gated by a one-time cryptographic code, and every step of the job is enforced by the server, not the app.

I designed and built the entire platform solo: two mobile apps (customer and runner), an authenticated backend API, and the security architecture underneath it — now deployed to production with real SMS authentication, a persistent PostgreSQL database, and a full transaction lifecycle that's been completed end-to-end by a real first-time user on her own phone.

The launch target is deliberate: the 2026 FIFA World Cup, with the Bay Area as a host region — tens of thousands of attendees per match converging on venues with nowhere to park. Acute, predictable demand meets a product built for exactly that moment.

The security model isn't a feature of this product. It is the product. The sections below show how it works.

The System

Two mobile apps, one authoritative backend, and a simple rule: clients ask, the server decides.

The customer and runner apps are built in React Native. Behind them sits a Node.js/Express API deployed on Railway, backed by a managed PostgreSQL database and Twilio Verify for SMS authentication. Every request — from either app — descends the full security stack before it touches data: rate limiting, JWT authentication, role-based authorization, ownership validation, and finally the state machine that governs every job.

No client is ever trusted to report its own truth. The apps are windows into the system; the server is the system.

Every request passes rate limiting → authentication → authorization → ownership → state validation before touching data. Verification codes never enter the application database.

Security Is the Product

Most apps add security around their features. Parking Genie's core feature is security — the entire product exists to solve one trust problem: a high-value item, handed to a stranger, twice.

So before writing a line of code, I mapped the attack surface. Who would try to steal a car through this system, and how? What could a malicious runner do? A fake customer? A compromised phone? A hacked client? Every control in the platform traces back to a specific answer in that threat model — nothing is decorative.

Nine attack scenarios mapped before development began. Each control exists because a specific threat demanded it.

The Server Is the Source of Truth

Every job moves through a fixed lifecycle, and the server alone decides what's legal. A client can request a transition — it can never declare one. A hacked app claiming a job is "complete" to trigger payment gets rejected the same way a wrong handoff code does: the transition simply isn't allowed from that state.

A job cannot reach completion without passing both verification gates, in order. There are no shortcuts, because shortcuts are exactly what an attacker would use.

I know the enforcement is real because it caught me. During testing, I tapped through the runner's checklist without entering the handoff code — and the server refused to advance the job. My own security model blocked its own developer. A security control you never bump into is a control you shouldn't trust.

Engineering War Stories

These are three real failures from this project — found, diagnosed, and fixed in production. Each one taught me something a tutorial never could.

The Opportunity

The wedge: major events create acute, predictable parking scarcity. The 2026 FIFA World Cup — with the Bay Area as a host region — concentrates tens of thousands of attendees per match onto venues with finite parking. Parking Genie launches into that exact moment, at those exact venues.

The moat is not the logistics — it's the trust layer. Anyone can dispatch a driver. What's defensible is a verifiable, tamper-evident chain of custody for a $40,000 item handed to a stranger: cryptographic handoffs, server-enforced state, and a forthcoming evidence layer of timestamped condition records. That layer is what makes premium pricing and insurance partnerships possible — and it can't be bolted on later, because it has to live in the core architecture. Here, it already does.

Built capital-efficiently: everything on this page — two apps, the security architecture, production deployment — was designed and shipped by one founder. Full roadmap, unit economics, and go-to-market available on request.

What's Next

Shipping honestly means knowing what isn't built yet. Here's the path from working product to World Cup launch — in deliberate order.

Sequencing is strategy: persistence before payments, payments before the evidence layer, evidence before scale.

Parking Genie — Trust, verified.

Source code private (active commercial project) · architecture walkthrough available on request

Simily Hill· www.linkedin.com/in/simily-hill/ ·build@udontsimi.io

Page updated

Report abuse