-
-
YardLeads AI Dispatcher turns a messy salvage-yard request into a structured, privacy-safe lead with GPT-5.6.
-
A worker enters an incomplete Ford truck request in plain language, ready for GPT-5.6 analysis.
-
A worker enters an incomplete Ford truck request in plain language, ready for GPT-5.6 analysis.
-
The app asks targeted follow-up questions so the worker can complete the lead without guessing.
-
A clear Honda Accord request is structured instantly with vehicle, part, timing, and fulfillment details.
-
The worker reviews editable fields, confidence, PII status, and public notes before posting the lead.
-
The confirmed lead is saved to Firestore with clean public fields, source tracking, and timestamps.
-
Structured data confirms the Honda, Accord, headlight, passenger side, and PII-safe public notes.
Inspiration
YardLeads was inspired by something I remember from the salvage yard business years ago.
Several yards located near one another used a shared speaker phone system that workers called the “red phone.” When one yard needed a part it did not have, a worker announced the request. Nearby yards could immediately respond if they had the part.
It was simple, fast, and practical.
Today, salvage yard workers still receive incomplete requests through phone calls, text messages, handwritten notes, and customers who may not know exactly what they need. Someone might say, “I need a computer for my ford truck,” without knowing the year, model, engine, module type, vin, or part number.
The worker then has to ask more questions, translate the request into useful information, and sometimes call other yards manually. This wastes time and can lead to lost sales.
I built YardLeads AI Dispatcher as a modern version of that red phone workflow. My goal is not to replace the worker. It is to help the worker quickly turn an incomplete customer request into a clean lead that another yard can understand and act on.
What it does
A yard worker enters a customer request in normal, everyday language.
GPT-5.6 then:
- Extracts the vehicle and part details that are actually present.
- Leaves unknown information blank instead of guessing.
- Identifies missing details that could affect part identification.
- Asks targeted follow-up questions when more information is needed.
- Produces a structured lead that the worker can review and edit.
Nothing is posted automatically. The worker must confirm the result before it is written to firestore.
For example, this request already contains enough useful information:
Need passenger headlight for an 2009 Honda accord coupe. Customer can pick up tomorrow.
The system identifies the year, make, model, body style, requested part, part position, urgency, and pickup preference.
A request like this requires clarification:
Customer needs a computer for a ford truck but does not know the year or model.
The system asks for details such as the year, model, engine, and whether the customer needs an engine control module, transmission control module, body control module, or another computer.
How we built it
I built the frontend with React, TypeScript, and Vite.
Firebase provides:
- Email-and-password authentication
- Cloud Functions
- Firestore
- Hosting
- Secret storage
The browser does not call OpenAI directly. It calls an authenticated Firebase callable function named analyzeLeadRequest.
That server-side function uses:
- The official OpenAI Node SDK
- The OpenAI Responses API
- GPT-5.6
- Strict JSON Schema structured output
store: false- Firebase Secret Manager for
OPENAI_API_KEY
After GPT-5.6 returns the structured result, the worker can edit every field before confirming the lead.
The public Firestore payload is created separately so the original customer request and clarification answers are not stored in the public part_leads document.
Codex helped me inspect the repository, create the Firebase Functions architecture, connect the frontend and backend, build the structured-output schema, add authentication, write tests, debug issues, and prepare the documentation.
Challenges we ran into
The biggest challenge was discovering that the first version only looked like a real AI integration.
The interface said it was extracting with GPT-5.6, but when I asked Codex to audit the implementation, I found that it was actually using hardcoded browser-side TypeScript, regular expressions, and limited lists of known vehicles and parts. There was no OpenAI API call.
I stopped there and directed Codex to replace the simulated parser with a real, authenticated, server-side GPT-5.6 integration.
Other problems I found and corrected included:
- A mismatch in the
clarificationAnswersrequest format - A login button that had no authentication handler
- Misleading form placeholders
- Clarification state carrying over between requests
- The risk of storing raw customer text in a public Firestore document
- The need to preserve unknown values instead of inventing details
The project also required careful coordination between frontend types, backend validation, strict structured output, authentication, secrets, and Firestore payloads.
Accomplishments that we're proud of
I am proud that I replaced the simulated parser with a real GPT-5.6 integration instead of submitting something that only appeared to use AI.
Other accomplishments include:
- Deployed an authenticated server-side OpenAI workflow
- Built a working clarification-question experience
- Preserved human review before posting
- Added editable structured fields
- Kept the OpenAI API key out of the browser
- Prevented raw requests and clarification answers from entering the public lead document
- Verified a sanitized lead in the live Firestore database
- Added automated frontend and backend tests
- Deployed the application with Firebase Hosting and Cloud Functions
- Documented what existed before Build Week in
BUILD_WEEK_BASELINE.md - Created a dedicated judge login and tested it in an incognito browser
What we learned
I learned that the most useful AI product for this problem is not a general chatbot.
A salvage-yard worker needs a focused tool that can:
- Understand informal automotive language
- Extract useful details
- Recognize what is missing
- Ask only relevant follow-up questions
- Avoid making up vehicle or part information
- Produce something the worker can quickly review
I also learned that AI-generated code must be inspected just like code written by a person. A result can look convincing while still being technically wrong.
Codex saved me a large amount of implementation time, but human review was necessary to catch the simulated parser, authentication issue, request-contract mismatch, privacy risks, and misleading placeholders.
What's next for YardLeads AI Dispatcher
This Build Week submission focuses on AI-assisted intake and clarification. It is not yet the complete YardLeads network.
My next step is to test the workflow with a small group of real salvage yards and measure whether it:
- Saves workers time
- Reduces incomplete requests
- Produces more useful leads
- Improves response rates
- Helps yards recover sales they would otherwise lose
Future versions could include:
- Voice-based intake for busy counter workers
- VIN decoding
- Evidence-based part-interchange assistance
- Shared-device worker mode
- Yard-routing recommendations
- Private customer contact storage with dedicated security rules
- Firebase App Check
- Notifications when another yard has the requested part
The long-term vision is to build a modern digital red-phone network that helps independent salvage yards work together, respond faster, and recover sales they might otherwise lose.
Built With
- codex
- firebase
- firebase-authentication
- firebase-functions
- firebase-hosting
- firebase-secret-manager
- firestore
- gpt-5.6
- node.js
- openai
- openai-responses-api
- react
- structured-outputs
- typescript
- vite
Log in or sign up for Devpost to join the conversation.