# Build brief — a focused alternative to Europe-Camions

> **Verdict:** Not faithfully · **Buildability:** 6/100 · **Category:** Commerce
> **Source:** https://www.canitbevibecoded.com/europe-camions
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Europe-Camions. Verify current pricing and capabilities before acting.

## Context

**Europe-Camions** — A European classifieds marketplace for used trucks, tractor units, trailers and commercial vehicles, mostly listed by dealers.

The software here is a search form over a database of listings, and yes, an agent can build that with a focused implementation. What it cannot build is the several thousand trucks that dealers actually bothered to upload, which is the entire product. A private clone launches with zero inventory and zero buyers, so it answers no queries and sells no trucks. The only honest personal build is a tracker that sits on top of listings you already found: watchlists, price history, diesel of a spreadsheet with better manners. Useful if you are shopping for one truck, worthless as a replacement.

This brief describes a focused, single-operator replacement for the part of Europe-Camions that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

A local watchlist app where you record trucks you are considering, track asking price changes over time, compare cost per kilometre and mileage, and get flagged when something you saved moves.

- Manage a small catalogue and checkout flow for products you fulfil yourself.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- Node 20 and a terminal.
- Listings you enter yourself, or feeds you have permission to fetch.
- No account or cloud service needed.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build a local truck shopping tracker called RigWatch. Single user, runs on my laptop, no accounts, no cloud, no telemetry.

Stack, no substitutions: Node 20, TypeScript, Express, better-sqlite3, EJS templates, plain CSS. No React, no ORM, no Docker.

Data model in SQLite:
- vehicle: id, title, make, model, year, mileage_km, engine_power_hp, axle_config, euro_class, body_type, country, dealer_name, source_url, notes, status (watching | contacted | rejected | bought), created_at
- price_point: id, vehicle_id, amount_cents, currency, seen_on (date)
- alert_event: id, vehicle_id, kind (price_drop | price_rise | stale), message, created_at, seen (bool)

Features, all server rendered:
1. Add and edit a vehicle by hand, including pasting a source URL. Optional: if a URL is given, fetch the page server side and try to prefill title and price from Open Graph tags and JSON-LD only. If that fails, leave fields blank and say so. Respect robots.txt, honour a 5 second timeout, do not crawl beyond the single URL given.
2. Record a new price point for a vehicle at any time. Show a sparkline or a simple bar list of price history plus total change since first seen.
3. List view with filters: make, country, euro class, year range, mileage range, status. Sort by price, mileage, price per 1000 km.
4. Compare view: pick two to four vehicles, render a side by side table of every field plus a computed value score (price divided by remaining useful mileage, with the assumed end of life km configurable in .env).
5. A single command, npm run check, that re-fetches every vehicle with a source_url, records a new price_point when the parsed price differs, writes alert_events for changes and for anything untouched in 30 days, and prints a summary. No background scheduler, no email.
6. CSV import and export of vehicles so a spreadsheet stays the source of truth if I want.

Out of scope, do not build: messaging sellers, payments, user auth, public listing pages, scraping search result pages, translation, image hosting beyond storing one image URL string.

Config in .env: PORT, DB_PATH, DEFAULT_CURRENCY, END_OF_LIFE_KM. Commit a .env.example, never a .env.

Deliver: npm install then npm run dev serving on localhost, a seed script with 8 fake trucks, and a README with the three commands and a one paragraph note that this tracks listings found elsewhere and is not a marketplace.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- The inventory: thousands of vehicles from dealers across several countries.
- The buyer side, so nothing you list gets seen.
- Dealer vetting and the loose trust layer that comes with a known marketplace.
- Multilingual reach across French, German, Dutch and Spanish speaking buyers.
- Cross referencing by make, axle configuration, euro emission class and body type on real data.

## What you still own after launch

- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.

## Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: low. No reviewed project implementation is linked yet.

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/europe-camions