Case study · 2026
eMUD: the off-road parts shop that first asks what car you drive.
An online shop for 4x4 parts and gear, with goods shipped directly by suppliers. You choose your car, by make and model or by chassis number (VIN), and the shop shows you only what fits. The same application grew a technical catalogue with an API and a register of car repair shops in Romania.
- Role
- Founder. Product, design, code, data
- Period
- August - September 2026
- Status
- Live on a-n.ro. The project is for sale
- Stack
- Laravel 12, Livewire 4, PostgreSQL, Redis
- The problem
- With off-road parts, the customer wants to know whether the part fits their car before paying.
- What I built
- A shop that starts from the customer’s car, a technical catalogue with a paid API and the national register of 12,974 repair shops.
- The result
- Live on a-n.ro, built in three weeks, with 807 automated tests. The project is for sale.
- 375 commits in three weeks
- 807 automated tests
- 105 data models
- 12,974 car repair shops in the directory
Counted in the repo and on a-n.ro, on 5 November 2026.
01 · The problem
“Does it fit my car?”
With off-road parts, the question is not only how much it costs, but whether it fits. A snorkel for a Duster does not go on a Jimny, and a suspension differs from one generation to the next. The customer wants a clear answer before paying.
On the other side, a shop that ships directly from suppliers receives product files in different formats, with stock and prices that change several times a day. To answer the first question, you first have to put the supplier files in order.
02 · What it does
Your car is the filter.
The customer picks their car from the make, model, generation, engine cascade or enters the VIN. Each product then gets a verdict: fits, does not fit or needs checking. In the account, “My garage” holds several cars, with technical data and reminders for the roadworthiness test (ITP), car insurance (RCA), oil and timing belt.
03 · The architecture
No source writes directly into the catalogue.
The basic rule of the catalogue: any information first comes in as a raw record, with its source, and reaches the final tables only after normalisation, matching and validation. Each source also has its own usage rights, so licensed data never reaches the public API.
- 01
Sources
- Supplier files, over HTTP or SFTP
- Vehicle data: NHTSA, EEA, Wikidata
- ECB exchange rates
- 02
Raw records
- Kept with source and date
- Normalisation and matching
- Conflicts sent for review
- 03
Canonical catalogue
- The technical part, separate from the product on sale
- Fitment rules, not rows per VIN
- OE codes, equivalents, replacements
- 04
Shop and API
- Best offer by final cost
- Selling price with markup and VAT
- API v1 with the sources in every response
Supplier stock updates every 15 minutes, prices every hour, and the full catalogue every night at 02:10.
04 · Components
Four products in a single application.
The shop
25 Livewire components for visitors and 11 for the account.
- Car selector and VIN search
- Cart, checkout, payment with Stripe or NETOPIA
- Shipping labels and tracking through FAN Courier
- My garage, with reminders for each car
- Guides and pages optimised for search
The technical catalogue
Explorer, quality panel and conflict queue, all in the admin.
- Sources, imports and raw records
- Matching supplier products to parts
- Unresolved relations, to check by hand
- Rights model for each source
- Separate demo data, with the DEMO- prefix
The paid API
The catalogue, sold as a service through RapidAPI.
- Make, model, generation, vehicle
- VIN and part codes, up to 50 per request
- Change feed with a cursor
- Keys, monthly quotas, four subscription tiers
- Published OpenAPI contract
The repair shop register
All car workshops in Romania, from public sources.
- RAR authorisations, companies from ONRC, OpenStreetMap
- Deduplication with a score on candidate pairs
- Normalisation of Romanian addresses
- Rule-based service classifier
- Off-road capability score
05 · The national register
On the first run, all 64 automatic merges were wrong.
The register starts from three public sources. RAR, the Romanian Automotive Register, provided about 13,000 repair shop authorisations, ONRC, the national trade register, 105,010 companies with a car repair activity code, and OpenStreetMap around 1,800 workshops. The same shop appears several times, with names and addresses written differently.
On the first national run, the system automatically merged 64 pairs. All of them were wrong: two different companies at the same address. I added a simple rule, two different tax codes mean two repair shops, and an automatic merge happens only when there is no doubt. The rest go into a review queue.
Also on the first production import, 282 roadworthiness test (ITP) stations did not get in: the tests ran on SQLite, which does not check column length, and PostgreSQL does. I widened the columns and learned to test on the same database as in production.
06 · Metrics
What I counted.
Measured in the repo, in the project documents and on a-n.ro. The shop is at pilot scale, so I do not publish sales figures.
- 375commits, between 24 August and 12 September 2026git
- 182commits in a single day: the catalogue platform and the APIgit
- 807automated tests, plus 724 checks in the repair shop module alonemeasured
- 105,010car repair companies from ONRC, analysed on the first runmeasured
- 15,040repair shop pages in the sitemapfrom the site
- 76%of RAR coordinates, only at town levelmeasured
How much code
- 105
- data models
- 95
- Livewire components
- 39
- commands
- 18
- queued jobs
- 128
- routes
- ~77k
- lines of code
07 · What I learned
What I take with me.
The part, the product and the offer are three things
The technical part is one thing, the product you sell is another, the supplier’s offer is a third. Mix them and you can no longer change supplier without breaking the catalogue.
A wrong automatic merge is worse than a duplicate
A duplicate can be seen and fixed. Two companies merged silently lose real data.
Test on the production database
SQLite hid column limits that PostgreSQL enforces. Tests now run on PostgreSQL, in CI too.
Suppliers must fail loudly
A supplier file that goes quiet is more dangerous than one that throws an error. Now every sync reports when it does not receive what it expected.
08 · For sale
The project is looking for a new owner.
eMUD is a complete base for a car parts shop built on fitment: shop, technical catalogue, API and repair shop register, with tests and documentation. If you are interested, write to me.
Want to take over eMUD, or do you have a similar project?
Write to me and I will send you the technical details and what the admin panel looks like.