Roadmap

A proposed build order with evidence gates. Phases run in sequence; nothing here commits to dates or cost. No production migration or charge is authorized by this plan.

Storage baseline requirements are documented and in development. Delivery, the courier app, organization administration, and the staff web cutover are proposed. Each phase below names its entry condition and the exit gate that must be met before moving on.

Related: Storage · Delivery · Platform · Release decisions

Each gate needs evidence before the next phase starts. Public launch also needs every release decision approved.

Phase 0 — Define the pilot operating contract

Entry: both delivery models are accepted as in scope: point handoff to a destination, and driver collection to a destination.

Define the first route in one service area with one organization and manual dispatch. For each custody transfer, name the responsible actor, the required proof, and the recovery path. Set quote, cancellation and refund, courier compensation, and settlement policy. Confirm service area, prohibited items, and support expectations.

Exit gate: an approved handoff sequence covers every step with actor, evidence, and recovery; both models have a defined path from paid order to verified delivery proof.

Phase 1 — Establish tenant-safe identity and ownership

Entry: Phase 0 gate met.

Map existing locations, bookings, staff accounts, and settlement data to real organizations with a rollback plan. Add organizations and membership records for organization admins, staff, and couriers, with oversight authority held separately from membership. Bind each location and booking to its organization and enforce that scope at every read and write boundary, including photos, reports, background jobs, and server-side routes. Only an authorized operator may grant elevated access.

Exit gate: no user can self-grant staff, courier, organization-admin, or oversight authority. One organization cannot read or change another's users, bookings, locations, photos, jobs, or reports. Existing customers can still manage their own bookings. Proven with negative authorization tests for each surface.

Phase 2 — Ship a paid, standalone delivery order

Entry: Phase 1 gate met.

Introduce a delivery order owned by a customer and an organization, with typed origin and destination, bag count, promised window, server quote, payment, and an optional link to the customer's own storage booking. Add a separate courier job and an append-only custody record with server-enforced transitions for assignment, acceptance, collection, transfer, delivery, exceptions, and cancellation. Add manual assignment and exception handling for organization operators, with customer-visible milestones and notifications. Retried payments and transitions are idempotent.

Exit gate: on the first pilot route, a standalone delivery order is paid once, assigned to one authorized courier, and delivered with verified proof. Wrong-organization references, duplicate requests, expired quotes, and missing proof cannot advance the order or double-charge.

Phase 3 — Build the courier app

Entry: Phase 2 gate met.

Build the proposed second app for couriers: sign-in, assigned-job list and detail, navigation handoff, pickup and delivery proof capture, exception reporting, and a durable retry queue for poor connectivity.

Exit gate: a courier completes an assigned pilot job on a real device. Other couriers — including another organization's couriers — cannot view or act on it. A retried offline proof produces exactly one server-side outcome and stays visibly pending until confirmed. First release is to an internal pilot group.

Phase 4 — Complete the website and staff cutover

Entry: Phase 3 gate met.

Separate oversight from organization operations on the website: organization admins manage only their own people, locations, bookings, deliveries, dispatch, and reports. Move the storage staff workflow — claim lookup, photo, tag, check-in and check-out, offline recovery — to a mobile-friendly staff web surface.

Exit gate: staff check bags in and out through the website with the required offline recovery. The staff route is removed from the traveler app only after on-device parity is demonstrated. Both delivery models have each passed end-to-end proof and exception scenarios. No customer or courier app contains an organization-admin surface.

Phase 5 — Reconcile delivery revenue and payouts

Entry: Phase 4 gate met.

Trace every delivery wallet debit, refund, and organization settlement back to its paid order without changing storage payment behavior. Confirm who pays couriers; automated courier payouts stay outside the first release. Approve service area, loss and damage terms, insurance, privacy retention, and partner and driver obligations.

Exit gate: a charged delivery, a cancellation with refund, and an organization report all reconcile to one order; storage payments and settlement still behave as before. Commercial and legal owners approve the US service terms.

Pilot and launch order

1. First route pilot with manual dispatch (Phase 2–3).
2. Second model proven on its own route with the same proof and exception gates (Phase 4 gate).
3. Public delivery launch only after both models, the staff cutover, settlement reconciliation, and all release decisions are approved.