Hold · My · Package

Neighborhood hubs for the last 100 meters.

Comment

The Pitch

Hold·My·Package is a B2B SaaS platform for neighborhood delivery hubs. When USPS, FedEx, UPS, or Amazon can't deliver a package — gated community, no safe drop spot, resident not home — the package gets rerouted to a local hub. The hub holds it and redelivers on the homeowner's schedule.

If the delivery driver has the right ZIP code, we handle the last 100 meters. The driver never makes a second attempt. They drop at the hub, and the homeowner gets it delivered to their door when they're actually home.

The platform serves three user types through four portals:

  • Hub Operators manage inventory, intake packages via barcode scan, dispatch geo-optimized delivery batches, and track analytics. They're the paying B2B customer.
  • Homeowners track packages, schedule redelivery windows, and receive real-time push notifications as their package moves through the system.
  • Carriers view rerouting stats, cost savings from avoided re-attempts, and integration details for their webhook pipeline.
  • Network Admins monitor a city-wide view across multiple hubs with coverage maps, utilization indicators, and aggregate metrics.

How it was built?

Next.js App Router on Vercel handles both the frontend and the API layer (serverless functions). UI components were scaffolded with v0, then wired to live backends and extended with custom business logic. Mapbox GL powers geographic visualizations. Pusher delivers real-time updates to connected clients.

The real-time pipeline: every status change writes an event to DynamoDB → DynamoDB Streams triggers a Lambda function → Lambda publishes to Pusher channels → connected clients update within 2 seconds. No polling anywhere in the system.

Geo features run at the database layer through PostGIS: nearest-hub matching via ST_DWithin, batch delivery optimization via ST_ClusterDBSCAN to group nearby deliveries into efficient routes, and coverage enforcement via spatial containment queries.

AWS Databases used and why

Aurora PostgreSQL (Serverless v2)

Aurora was chosen specifically for its extensions and constraint system:

  • PostGIS — nearest-hub routing (ST_DWithin), coverage geo-fencing, and ST_ClusterDBSCAN for batch delivery optimization. A delivery batch that requires dozens of API calls in application code runs as a single SQL statement at the database layer.
  • Row-Level Security — homeowner A cannot access homeowner B's data, enforced by the database itself. Even a compromised API route cannot bypass this — the database rejects unauthorized access structurally.
  • Exclusion constraints — delivery slot booking uses temporal exclusion constraints. Two concurrent requests for the same time slot cannot both succeed. Scheduling correctness guaranteed without application-level locks.
  • Materialized views — dashboard analytics (average hold time, carrier performance, success rates, peak hours) are pre-computed. Dashboards load in milliseconds.
  • Window functions — smart delivery window suggestions analyze historical scheduling patterns using SQL-native intelligence. No external ML service required.
  • Advisory locks — prevent double-intake of the same package when multiple operators work simultaneously.

DynamoDB

DynamoDB was chosen for the high-throughput event pipeline and its operational primitives:

  • Single-table design — one table with composite keys (PK: PKG#{id}, SK: EVENT#{timestamp}#{type}) serves four access patterns via 3 Global Secondary Indexes. Package timeline, homeowner feed, hub live view, and carrier daily report — all from one table.
  • Conditional writes — optimistic concurrency on status transitions. Two requests cannot simultaneously move a package from "held" to "dispatched." Correctness without distributed locks.
  • DynamoDB Streams — every event write triggers a Lambda function that pushes to Pusher channels. This is the backbone of the real-time architecture: status change → DynamoDB → Stream → Lambda → Pusher → all connected clients update.
  • TTL — events auto-expire after 90 days. Before deletion, the Stream captures them for archival. Built-in lifecycle management without scheduled jobs.
  • GSI 1 (HomeownerIndex) — homeowner_id + timestamp for chronological feed.
  • GSI 2 (HubIndex) — hub_id + timestamp for operator live view.
  • GSI 3 (CarrierDailyIndex) — carrier#date + timestamp for carrier reporting.

Why two databases?

Aurora handles relational data — users, packages, hubs, schedules, spatial queries, analytics. DynamoDB handles the high-throughput event stream — status changes, notifications, real-time updates. Aurora gives us ACID transactions, PostGIS, and RLS. DynamoDB gives us sub-millisecond writes, Streams-driven push, and single-digit-millisecond reads across four access patterns. Each database does what it was designed to do.

The Business

  1. The last 100 meters. Existing hub solutions require the customer to come to the package. Hold·My·Package redelivers to the homeowner's door, on their schedule. The package comes to you.
  2. Carrier-agnostic. One hub handles USPS, FedEx, UPS, and Amazon packages simultaneously. No exclusive carrier partnerships required. Any failed delivery in the ZIP code gets caught.
  3. Neighborhood-operated. Local businesses run the hubs — a dry cleaner, a convenience store, a co-working space. They use existing space and staff to offer a service their neighborhood already needs. The platform brings them carrier partnerships, a homeowner network, and the software to manage it all.
  4. Three-sided value. Carriers pay per-package routing fees to hubs — still far cheaper than re-attempting delivery themselves. Hub operators earn that routing revenue; the platform subscription pays for the software and integrations that make it possible. Homeowners use it free — they're the demand that makes the network valuable to both other sides.
  5. Database-native intelligence. PostGIS clusters nearby deliveries into batches. Window functions detect scheduling patterns. Materialized views power analytics dashboards. The intelligence lives in the database layer — no external ML services, no inference costs.
  6. Event-driven real-time. Every status change ripples across all connected clients in under 2 seconds. Operators see intake happen live. Homeowners get push notifications the moment their package moves.

How to use

Click "Watch Live Demo" on the landing page. A guided tour walks through the complete package lifecycle — starting as a hub operator (intake, dispatch, analytics), then switching to the homeowner view (tracking, scheduling, notifications). After the tour, explore any of the four portals freely using the role cards.

Track

Track 2 - Monetizable B2B App

Tech Stack

Next.js (App Router) on Vercel, v0 (UI scaffolding), Aurora PostgreSQL Serverless v2 (PostGIS, RLS, materialized views, exclusion constraints), DynamoDB (single-table design, Streams, conditional writes, TTL), AWS Lambda, Pusher Channels, Mapbox GL JS, shadcn/ui, Tailwind CSS, TypeScript

Built With

  • app-router-on-vercel
  • aurora-postgresql-serverless-v2
  • aws-lambda
  • dynamodb
  • mapbox-gl-js
  • next.js
  • postgis
  • pusher-channels
  • rls
  • tailwind-css
  • typescript
Share this project:

Updates