FULL-STACK DEVELOPMENT / 2026
Navarro Co.
A storefront up front.
A working system behind it.
Vehicle browsing, seller submissions, enquiries, and staff tools in one FiveM application.
Inventory, enquiries,
and the staff work behind them.
- My contribution
- Storefront, staff console,
API & deployment
- Project context
- FiveM community software
Documented build · July 2026
- Built with
- React · Hono · Cloudflare Workers
D1 · R2 · Workers AI
01 / THE PRODUCT
The showroom is only
half the product.
Browsing vehicles is the visible part of a dealership website. Behind it, someone still needs to maintain inventory, review cars offered for sale, respond to enquiries, and keep track of staff activity.
I built Navarro to connect those responsibilities in one application: a public-facing storefront and an authenticated back office, supported by a shared API and data layer.
ONE PRODUCT / TWO PERSPECTIVES
Browse. Enquire. Offer a car.
The public experience combines vehicle inventory with customer enquiries and a “sell us your car” intake flow.
- Explore the vehicle inventory
- Send a customer enquiry
- Submit a vehicle for review
Manage what’s behind the listing.
Inventory, valuations, enquiries, and audit history, with AI-assisted notes and a cached briefing.
- Manage inventory & valuations
- Review submissions & enquiries
- Inspect activity & briefings
Different users. Shared application.
Staff access uses individual accounts, not a shared passcode.
02 / HOW THE WORK MOVES
Follow a vehicle submission.
See where a vehicle submission goes, and why pricing rules stay separate from an AI-written note.
WORKFLOW EXPLAINER
From submission to staff review
Offer a vehicle
A customer submits a car for staff to review.
Staff review
The submission enters the dealership’s internal workflow.
Catalog-based range
Defined percentages calculate the buy range.
AI-written note
Generated prose supports the appraisal.
Start with the customer’s submission. It gives staff a vehicle to review; it does not automatically approve the vehicle for inventory.
03 / UNDER THE SURFACE
One application.
Clear responsibilities.
The interface, application logic, records, photos, and generated assistance each have a distinct job.
INTERACTIVE FIGURE
One application. Clear responsibilities.
01 / Experiences
↓ API requests connect to the Worker
02 / Application
↓ Separate branches—not a pipeline
03 / Services & assets
Application layer
Hono / Worker
API requests are handled under /api. Other routes fall through to static React assets. D1, R2, and Workers AI have separate responsibilities—not consecutive stages in a pipeline.
Read all component descriptions
- Public storefront
- Vehicle inventory, customer enquiries, and a “sell us your car” intake flow. This is the public-facing side of the documented application.
- Staff console
- Individual staff accounts access inventory, valuations, enquiries, and audit history. It shares the application API with the storefront.
- Mobile-app mock
- The /app route is rendered in an iOS-style frame. The source describes a mock interface, not a shipped native mobile application.
- Hono / Worker
- API requests are handled under /api. Other routes fall through to static React assets. D1, R2, and Workers AI have separate responsibilities—not consecutive stages in a pipeline.
- D1 database
- Inventory, submissions, sales, enquiries, and cached AI results. This is structured application data, separate from the photo files stored in R2.
- R2 storage
- Vehicle and submission photos. In the original account, photos were served through the Worker without an image-resizing pipeline.
- Workers AI
- Appraisal notes, enquiry triage, and a scheduled business briefing. The model does not calculate buy ranges; those come from catalog-based rules.
- Static assets
- Non-API requests fall through to the ASSETS binding, which serves the static React application. This is a separate route from the data and AI services.
04 / AN ENGINEERING DECISION
AI helps explain.
It does not set
the numbers.
Buy ranges are calculated from the pricing catalog using defined rules. The language model contributes an appraisal note; it does not invent the number a staff member is expected to use.
The daily briefing is generated on a schedule and cached, so viewing the dashboard does not require a fresh model response.
A DELIBERATE BOUNDARY
Rules
calculate.
Pricing catalog
+ tier percentages
→ buy range
AI
explains.
Appraisal context
+ language model
→ written note
The system uses AI to assist the workflow, not to become the authority behind it.
05 / BEYOND THE HAPPY PATH
Staff access, public input,
and the gaps in the tests.
The documented build includes controls for staff access, public input, and activity history. The API integration suite exercised the Worker with local D1 and R2; frontend coverage remained a gap.
Individual staff identity
Per-account staff logins with HMAC-signed session cookies. No shared passcode.
Public endpoint controls
Rate limiting on login and public forms. Server-side Turnstile verification when both keys are configured. Local substitutes do not verify deployed enforcement.
Defined input boundaries
Text-length caps, restricted image keys, a 3 MB upload cap, and response security headers.
Activity history
An append-only audit log for admin actions in the original account. This is not a claim of an independent security audit.
WHAT THIS PROJECT DEMONSTRATES
More than a finished interface.
01 / DELIVERY
End-to-end
engineering.
A public interface, an internal console, an API, storage, and deployment—not just an isolated landing page.
02 / JUDGMENT
Practical
AI boundaries.
Language-based assistance sits beside deterministic valuation rules rather than replacing them.
03 / OPERATIONS
Attention to
the less visible work.
Staff identity, input limits, audit history, testability, and failure behavior are part of the engineering story.
About this sample & its evidence
This is an interactive presentation of the supplied Navarro rewrite. It describes the July 3, 2026 project account, not a newly audited release. The image is the original 297 × 185 thumbnail. Diagrams are labeled explanations, not authenticated staff screenshots or live application data. Planned investor features are not included.
The original API test count and hosting-cost account are historical, not fresh measurements. The production repository, current deployment, and security configuration were not re-verified. Original published article ↗