ParkPal

DynamoDB Proof of Use

Inspiration

We grew up in Seattle. If you know Seattle, you know parking is a contact sport.

Between Mariners games, Seahawks Sundays, concerts downtown, and entire neighborhoods flooding for World Cup matches, there are days where finding a spot within a mile of your destination feels impossible. The breaking point came at a Kelsey Creek Farm community event — the lots were completely full, drivers were lapping the same block, and then we looked across the street.

Empty driveways. Everywhere.

So we looked into it. In Seattle, the average household wastes 3.3 parking spaces. Designated spots cost upward of $30,000 each to build and thousands per year to maintain — which means the supply problem isn't going away through construction. The supply is already there. It's just sitting idle in people's driveways.

That's ParkPal: a two-sided marketplace where homeowners list their unused driveway space, and drivers find and book it in real time.

The Legal Wrinkle

Here's the honest version: nobody is entirely sure what category we belong to.

There are regulations for parking garages. There are regulations for short-term rentals. There are regulations for rideshare. But ask a city planner whether a homeowner can rent out their driveway for three hours before a game, and you'll get a very long pause.

We're not a garage. We're not Airbnb. Seattle, Bellevue, and Tacoma each have zoning restrictions on commercial use of residential property — but whether a driveway rental counts as "commercial use" is genuinely unsettled. Washington State classifies short-term parking as a "License to Use Real Property", which means hosts owe retail sales tax and B&O tax. HOA bylaws matter. Liability under Washington Premises Liability Law matters.

So we started doing outreach before we finished the app: property managers, HOAs, insurers, city planning offices. We've received letters of intent from organizations like PMI Arka, a property management firm exploring future collaboration. The regulatory path is work, but it's not a wall.

What we found when talking to real homeowners and drivers is that the first question was never "who needs parking?" It was: "What happens if something goes wrong?"

That shaped what we built.

How we built it

For the H0 Hackathon's Dynamo track, we built ParkPal's backend entirely on AWS DynamoDB and S3, deployed to Vercel. The frontend is Next.js, TypeScript, Tailwind, Stripe (test mode), and Mapbox.

Data model Ten DynamoDB tables, all prefixed pp_, organized into three logical groups:

Identity Marketplace Messaging pp_users pp_listings pp_conversations pp_profiles pp_listing_photos pp_messages pp_vehicles pp_bookings pp_favorites
pp_reviews
All items are stored snake_case. Every access pattern that isn't a direct key lookup gets its own GSI so there are no full-table scans in the hot path:

Query GSI Log a driver in by_email A host's listings by_host A driver's reservations by_driver Reviews on a listing by_listing Both sides of a chat thread by_participant Everything runs on on-demand billing — no capacity planning, no cold starts.

Auth JWT httpOnly cookies, signed server-side with bcrypt on pp_users. The browser never reads the token directly. Every protected route derives the authenticated user from the session — the client never passes a user ID.

Storage S3 presigned PUT URLs for photo uploads. The browser uploads directly to S3 without touching the server. A same-origin /api/img route proxies images back to the client so credentials never leave the server.

Payments Stripe Checkout in test mode, with escrow semantics: payment holds until the reservation completes, then releases to the host minus platform commission. Payment verification happens on the redirect — the server re-fetches the Checkout session and confirms payment_status === "paid" before marking the booking escrowed.

Deployment vercel --prod 33 routes. Build green. 10 pp_* tables live in us-west-2.

Challenges we ran into

The trust problem came before the tech problem. Every feature we spec'd for the "boring" side of the product — license plate verification, photo check-ins, host agreements — turned out to matter more than the map or the booking UI. You can build a beautiful discovery flow, but if a host can't verify which car is in their driveway, nothing else matters.

DynamoDB's access-pattern discipline. Coming from a relational background, the shift from "add a WHERE clause" to "model a GSI at schema time" is a real one. Designing the index set upfront so that every query in the application hits a partition key or GSI — and never triggers a scan — required thinking about the full access graph before writing a single route. Getting that right meant the query layer is fast everywhere, not just in the happy path.

Server-side trust at every boundary. With DynamoDB as a server-only resource (no browser SDK), every data call became a Next.js server action. That's actually a feature — the server always derives identity from the session, and the client never passes a user ID it could forge — but it required rethinking every place the frontend had previously called a database directly.