Auto workshops run on details that ERPNext core was never shaped to hold. A vehicle is not just a customer and not a serial number in the way a garage thinks about it — it has a registration plate, VIN, make/model/year, and an odometer that climbs across dozens of visits and sometimes multiple owners. ERPNext gives you Sales Order, Delivery Note, Stock Entry, and Timesheet, but nothing that models "this Corolla came in for brakes, here is who inspected it, what we quoted, which mechanic did the labor, and which parts we consumed." Teams end up tracking that in a spreadsheet or a WhatsApp thread, and the workshop quietly loses money on parts that were fitted but never billed and labor hours that were never captured.

We build a proper Frappe app — its own installable module, not a pile of ad-hoc customizations bolted onto stock DocTypes — that adds the automotive layer ERPNext is missing. The core is a Vehicle DocType (plate, VIN, make, model, year, engine, customer link, odometer log) and a Job Card / repair-order DocType that ties a vehicle to the incoming complaint, an inspection checklist, a service estimate, assigned mechanics, labor lines, and consumed spare parts. Job cards move through a defined state machine (Received → Inspection → Estimate Approved → In Progress → QC → Ready → Invoiced) using Frappe's Workflow engine, so nothing skips a step and every transition is permission-gated by role.

Under the hood, the automation lives where Frappe intends it to. hooks.py doc events (on_submit, validate, on_update) drive the money-and-stock side: approving an estimate reserves parts, closing a job card posts a Stock Entry for consumed inventory and creates a draft Sales Invoice that already carries the labor lines plus parts at your markup, so nothing gets fitted and forgotten. Server scripts and scheduler events handle the background work — service-due reminders based on odometer or elapsed time, aging alerts on open job cards, and daily technician-utilization rollups. Spare parts use ERPNext's native Item, Batch, and Stock Ledger, extended with barcode scanning on the parts-issue screen via a client script so the counter fits the exact part off the shelf. Everything is reachable over the Frappe REST API and purpose-built whitelisted methods, so a reception tablet, a mechanic's phone, or a future customer portal can read and write job cards without touching the database directly.

Because this is build-to-order, we start from your actual workflow, not a generic template. After a short scoping call we confirm the DocType fields, the exact job-card states your shop uses, your labor-rate and parts-markup rules, role profiles (Service Advisor, Mechanic, Parts Counter, Manager), and print formats for estimates, gate passes, and invoices. We build against Frappe/ERPNext v15 or v16, test on a staging copy of your data, run UAT with your team, and only then deploy to production — with a rollback plan ready the whole time. Typical delivery is one working week from confirmed scope, and you receive the full app source in a git repository you own.