PartYard
A private operations platform for an automotive dismantling business. Model-specific catalogues connect donor intake, inspection, individual part preparation, storage, reservations and sales in one traceable workflow.
- Role
- Full-Stack Developer
- Stack
- Next.js · React · TypeScript · MongoDB
- Focus
- Private Production System
- Initial development
- Jul 2026 – Sep 2026
Automotive Inventory & Operations Platform
- Seven vehicle families across Toyota, Honda and Ford
- 607 vehicle templates with configuration-specific parts
- Full vehicles, partial arrivals and individual parts
- Multilingual search with aliases and typo tolerance
- Individual part records from preparation to sale
Overview
PartYard replaces a set of disconnected spreadsheets and manual routines with one internal system. Vehicles enter as donors, get inspected, become inventory, then move through reservation, sale and reporting — all inside the same application.
The difficult part was not building another inventory interface. It was translating the real dismantling workflow into software: defining what parts should exist for a specific vehicle, understanding what portion of that vehicle actually arrived, and following each physical part through the rest of the operation.
The Business Problem
The business imports donor vehicles into Georgia, dismantles them, stores the usable parts and sells those parts. A donor may arrive complete, as only a front or rear section, or with individual components already missing or damaged.
The system therefore needed an accurate parts baseline without forcing employees to confirm hundreds of normal records manually. Reliability, fast data entry and interfaces that work on a phone in the warehouse were operational requirements rather than presentation details.
Engineering challenge 01
One Catalogue, Multiple Vehicle Families
The catalogue began with Toyota Camry and a practical problem: a generic parts list could not describe what a dismantling business actually receives, checks and sells. It also needed the terminology people use in the Georgian automotive market, alongside English and Russian names.
I built a structured catalogue that separates part definitions from vehicle templates. Each template selects the relevant parts for a model year and configuration, while additional components remain available for manual selection. Generation, powertrain, drivetrain and trim data keep the expected inventory tied to the selected donor.
The current catalogue covers Toyota Camry 2025–2026, Honda Accord 2025, Toyota Grand Highlander 2025, Toyota Sienna 2026, and Ford F-150, F-250 and F-350 from 2008–2026. It contains 1,362 catalogue definitions and 607 vehicle templates across seven vehicle families.
A catalogue entry can describe
- English, Russian and Georgian names
- Aliases, workshop terms and OEM references where available
- Category, position and left/right side
- Assemblies and separately selectable components
- Automatic inventory entries and optional manual additions
- Vehicle family, model year and configuration applicability
1,362
structured catalogue definitions
607
vehicle configuration templates
7
vehicle families in the catalogue
Camry established the catalogue structure. Other vehicle families use the same model: shared part definitions, configuration-specific templates and a separate record for each physical item in stock.
Engineering challenge 02
From Vehicle Configuration to Expected Inventory
A donor may arrive as a complete vehicle, a front or rear section, selected zones, or just a handful of individual parts. The software needs to distinguish a part that never arrived from one that should have arrived but is missing or damaged.
The vehicle template establishes the parts baseline, and the received configuration defines the inspection scope. Parts outside that scope are recorded as not received rather than counted as missing. When only individual parts arrive, the operator selects those parts directly without generating a full vehicle's stock.
Inspection focuses on exceptions. Each physical unit has its own inventory record, so two identical parts can carry different conditions, photos, prices, storage locations and sales histories.
Supported received configurations
Full vehicle
Front section / front half
Rear section / rear half
Selected vehicle zones
Individual parts only
Inventory philosophy
A defined baseline for whole vehicles. Direct selection for individual parts.
Templates remove repetitive entry when a vehicle or section arrives. Inspection records deviations within the received scope. Small deliveries use direct part selection, and duplicate items remain separate physical units throughout the workflow.
What I Built
Vehicle Intake & Catalogue
- Separate make and model selection with configuration-specific templates
- Optional VIN and structured donor vehicle details
- Seven vehicle families with automatic and manual part coverage
Inspection & Preparation
- Inspection scoped to the received vehicle or parts
- Missing, damaged and not-for-sale exceptions
- Preparation queue for photos, pricing and storage location
Inventory & Search
- One stock record per physical unit, including identical parts
- English, Russian and Georgian names, aliases and OEM lookup
- Transliteration, keyboard-layout correction and typo tolerance
Reservations & Sales
- Reservations with customer details and expiry dates
- Recorded sales and a traceable history for each part
- MongoDB transactional operations where required
Analytics & Reporting
- Sales, donor expenses and period-based operating results
- USD and GEL reporting kept separate
- Excel exports for sales and vehicle inspection reports
Media & Storage
- Image uploads with presigned AWS S3 URLs
- Delivery through AWS CloudFront
- Zod validation across API boundaries
Smart Search
The custom catalogue contains both formal terminology and the words people actually use in the Georgian automotive market. Search had to absorb that reality instead of forcing warehouse staff to remember one canonical name.
System workflow
From Template to Inventory History
The data model follows the order of the physical operation. Each stage establishes the context required by the next one.
Vehicle template
Donor vehicle
Received configuration
Expected inventory generation
Exception-based inspection
Dismantling and part processing
Photos, storage location and pricing
Reservation or sale
Inventory history and analytics
Architecture
Frontend
Next.js, React, TypeScript, Tailwind CSS
Application layer
Next.js route handlers and server logic
Database
MongoDB with Mongoose schemas and transactions
Media storage
AWS S3 presigned uploads, CloudFront delivery
Validation
Zod schemas shared across boundaries
Deployment
Vercel
Secure HttpOnly cookie authentication
What the system enables
One operational record from arrival to sale
Vehicle templates, inspection scope and individual stock records give the business one consistent view of its operation across the supported models. Intake, preparation and sales use the same underlying data.
Gallery
Project privacy
PartYard is a private operational system, so production access is not public. These screenshots illustrate the workflows with demonstration data; identifying and financial details are redacted.
Need a system for your own workflow?
Inventory, inspections, reservations or reporting: I can build an application around how your team works, with an admin interface and the backend behind it.
Next project
Professional Training and Employment Center
Vocational Training, Certification & Verification Platform