Handoff notes
Demo entry, assumptions, limitations and rationale
Everything a reviewer needs to operate and judge this prototype without a private explanation.
Demo entry
Open /account and either use one-click entry (“Enter as owner-operator” / “Enter as fleet manager”) or sign in with:
- Owner-operator: driver@demo.fleethaven.test / demo-driver
- Fleet manager: fleet@demo.fleethaven.test / demo-fleet
The demo session is stored in browser localStorage only. LiveView can also be unlocked directly from /liveview. A simulated reservation can be completed from /reserve without an account.
Design rationale
Audience routing
- — The home page routes the three core audiences in one band above the fold on desktop and immediately after the hero on mobile: drivers to /reserve, monthly customers to /monthly, fleets to /fleet.
- — Driver conversion gets the strongest CTA weight; fleet credibility is carried by claim-status transparency and business billing options rather than by louder marketing.
Brand system
- — Temporary typographic wordmark: Archivo extrabold uppercase with a safety-amber second syllable and a superscript TM. No elaborate logo is proposed.
- — Palette: graphite steel surfaces, safety amber primary, signal cyan for data, plus success/warning/destructive status colors. All values are oklch tokens in src/styles.css.
- — Type: Archivo for headings, IBM Plex Sans for body, IBM Plex Mono for identifiers, counts and codes — machine-readable data reads as data.
- — Imagery is deliberately vector/diagrammatic. No stock photography of giant terminals, hundreds of trucks or a FleetHaven fuel plaza.
Conversion strategy
- — Reserve flow is four visible steps with a persistent price panel and a single primary action per step.
- — Availability search shows a loading state, a zero-availability state and per-space-type sample rates so a driver can compare quickly on a phone.
- — Fleet flow substitutes a capacity request and billing-preference selection for consumer card checkout.
Scalability
- — All catalog, rate, camera, amenity and account data lives in a single typed module (src/lib/fleethaven.ts) so a second location becomes another data set, not a redesign.
- — Location is treated as a selectable dimension in the reserve flow, and zone identifiers are shared between reservations and LiveView entitlement.
- — Claim status is a first-class data field, so a capability can move from planned to opening-day without editing page copy in many places.
Assumptions (professional judgments)
Recorded decisions
- — Illustrative rates, fees (6% facility fee) and tax (7%) are invented placeholders chosen only to demonstrate breakdown math; they are labeled illustrative everywhere they appear.
- — Space-type taxonomy (standard combination, pull-through, reefer-ready, trailer drop) and zone names A–D are prototype constructs, not a site plan.
- — Cancellation, no-show, payment-failure, incident, insurance and abandoned-equipment policies are written as placeholders to show structure; they are not legal text.
- — The site diagram is an abstract concept sketch rather than an aerial or plan overlay, to avoid implying an approved layout or a selected fuel operator.
- — No street address is published for the campus beyond the corner description in the brief; the 1737 Shaw Road parcel is referenced only in the property-status context.
- — No phone number or email address is published, because no operating support line exists; support is demonstrated through in-app routes instead.
- — Single dark visual theme with no light/dark toggle, chosen for yard-at-night legibility and brand consistency.
- — Location selection in the reserve flow is fixed to Fayetteville because no other location is planned; the control exists to show multi-location architecture.
Mock integrations and limitations
Simulated, not connected
- — Payments: no processor, no card fields, no tokenization. Checkout is a timed simulation.
- — Availability and inventory: static sample counts; no reservation engine or concurrency handling.
- — Email/SMS: no confirmations are sent. Confirmation screens display on-page only.
- — File uploads (COI, service photo): the file name is read in the browser; no file is transmitted or stored.
- — LiveView: every frame is generated SVG. No cameras, streams, URLs or credentials exist in the code.
- — Mobile-service dispatch: provider responses are canned sample text; no provider network is connected.
- — Shop: catalog is static; orders, inventory, tax and shipping are not implemented.
- — Accounts: two fictional demo profiles held in localStorage. No database, no authentication, no personal data.
Not implemented in this prototype
- — Downloadable mobile app (future/conditional in the brief).
- — Real-time notifications, digital gate actuation and credential provisioning.
- — Multi-location switching UI beyond the architectural seam described above.
- — Reporting exports (CSV/PDF) from the fleet dashboard.
- — Server-side persistence of demo actions between sessions or devices.
- — Automated accessibility and performance test suites; accessibility was implemented against WCAG 2.2 AA practices (semantic landmarks, labeled controls, visible focus, keyboard operability, reduced-motion support, status roles) but not third-party audited.
Truth discipline checklist
How claims are constrained
- — FleetHaven is never described as open, operating or accepting real reservations.
- — Approximately 6.14 owned acres, the 0.56-acre parcel under contract and the ~6.70-acre post-closing assemblage are presented separately, with the ~2.84-acre corner shown as 2.28 acres currently C3 plus the parcel under contract.
- — Current R6A zoning is distinguished from the adopted future commercial (C3 / C(P)) designation; rezoning is never described as complete.
- — Round 2: AADT counts and traffic-study data were removed from the homepage, footer and all marketing pages. Public location content now describes route access and I-295 proximity qualitatively, with no traffic volumes, no station IDs and no intersection totals stated anywhere.
- — All photography is generated concept imagery, labeled on every instance; no built facility, tenant, brand or person is depicted as real.
- — Drone-assisted monitoring is labeled planned and subject to feasibility, privacy rules and FAA plus local operating approvals — never an opening-day capability.
- — The truck scale appears only as: “Commercial truck scale — planned, subject to feasibility.” No certification, legal-for-trade or accuracy claim is made.
- — The FleetHaven App is labeled planned throughout; store buttons are disabled placeholders and no listing, download or notification delivery exists.
- — Yard-map bays, space numbers, inventory states and prices are demonstration data. Selecting a bay holds nothing and processes no payment.
- — Round 2 addendum: the secured yard is presented as professionally graded, compacted crushed-stone gravel engineered for heavy commercial vehicles — never asphalt or concrete. Hero, yard, gate, drone and app imagery were regenerated on gravel, painted striping was removed, and spaces are organized with numbered posts, bollards, wheel stops and edge markers. Only a short paved public-road or gate apron appears. Surface design, drainage and maintenance specifications are not engineered or approved.
- — The fuel/convenience pad is shown only as a potential separate operator concept; no operator is named or depicted and no gas station is implied to exist.
- — Capability claims carry an explicit status: opening-day target, planned subject to feasibility, or future/conditional.
- — FleetHaven™ appears without the ® symbol throughout.
Search, AI answer engines and launch checklist
How metadata works here
All brand facts and per-route metadata live in one typed file: src/lib/seo.ts. Each route calls routeHead(), so titles, descriptions, robots directives, Open Graph and Twitter tags and JSON-LD are server-rendered in the initial HTML and never duplicate after in-app navigation.
No permanent FleetHaven domain exists yet, so nothing is invented. Set VITE_PUBLIC_SITE_URL to the confirmed production origin and the site starts emitting canonical URLs, og:url, absolute JSON-LD IDs, sitemap URLs and the sitemap line in robots.txt. Until then, every page sends noindex, nofollow, noarchive, and localhost and Lovable preview hostnames can never be canonicalised or indexed.
Structured data limits
- — Organization and WebSite nodes describe FleetHaven explicitly as a planned business. A WebPage node is added per indexable page and linked with isPartOf and about.
- — No LocalBusiness, Place, geocoordinates, openingHours, address or telephone: FleetHaven is not open and no confirmed public address, phone or hours were supplied.
- — No Product, Offer, price, availability, AggregateRating, Review, Event, HowTo or SearchAction. Demo rates, inventory and reservations are never marked up as real.
- — The Quick answers block on /support is visible page content only. FAQPage schema is deliberately not used.
- — Automated tests cover title/description uniqueness, noindex routes, sitemap inclusion and exclusion, JSON-LD parsing and the forbidden schema list (src/lib/seo.test.ts).
Crawler policy
- — robots.txt and sitemap.xml are real server routes returning text/plain and application/xml — never SPA HTML.
- — Googlebot, Bingbot and OAI-SearchBot (AI search and citation) are allowed on public production pages, plus a generic User-agent: * Allow: / rule.
- — GPTBot (model training) is disallowed by default as a privacy-conservative choice. Flip ALLOW_AI_TRAINING in src/routes/robots[.]txt.ts to change it.
- — /account and /handoff are noindex in every environment and excluded from the sitemap. They are intentionally not blocked in robots.txt, so compliant crawlers can read the noindex tag.
- — Non-production hosts return User-agent: * / Disallow: / and an empty sitemap, so no preview URL can be indexed.
- — The sitemap omits lastmod because no authoritative per-page content-modified date exists; stamping build time would be false.
Launch tasks that need the confirmed domain or real business facts
- — Set VITE_PUBLIC_SITE_URL to the confirmed production origin, then redeploy and re-check canonicals, og:url and JSON-LD IDs.
- — Fetch /robots.txt and /sitemap.xml on production and confirm the content types, the absolute sitemap URL and the excluded routes.
- — Validate JSON-LD with the Schema Markup Validator and Google's Rich Results Test.
- — Verify the property in Google Search Console and Bing Webmaster Tools, then submit the sitemap.
- — Create the IndexNow key only after the real domain exists, and submit changed URLs from then on.
- — Revisit schema when facts are confirmed: a public address, phone and hours would justify LocalBusiness, and real published rates would justify Offer. Not before.
- — Replace concept imagery and the social preview image with real photography once the yard is built.
Source export and setup
The full source is available through this project’s export/GitHub option. It is a TanStack Start + React + Tailwind CSS v4 application.
bun install # or npm install bun run dev # http://localhost:8080 bun run build # production build
Key files: src/styles.css (design tokens), src/lib/fleethaven.ts (all prototype data), src/components/site/ (shell, primitives, demo auth), src/routes/ (one file per page). No backend, no environment variables and no external services are required.