Heavy Ops
B2B platform matching heavy-equipment companies with eligible, compliant machine operators, with an explainable arrival-bonus workflow
- Pre-pilot (private)
- 2026
- 52 commits last push Oct 2026
- Python 3.12 FastAPI Pydantic v2 SQLAlchemy 2 Alembic PostgreSQL PostGIS React TypeScript Vite pytest
- Private repository
A gated eligible-opportunity feed, not a public job board. The platform never moves money: a confirmed arrival bonus is recorded, not paid. Most of the engineering is in deciding who is allowed to see what, and proving it.
Private repository. Described from its architecture and status documents only.
Problem
Urgent operator requests travel over WhatsApp and spreadsheets. Companies cannot verify credentials quickly, operators see jobs they are not eligible for, and nobody can explain afterwards why one operator was chosen.
Flow
- A company publishes a structured request for a machine role at a project site.
- Eligibility is computed and persisted per operator with ineligibility reasons and a score breakdown.
- Only eligible operators see the request; an optional arrival bonus in CLP rises within a company-set band until one accepts with a committed ETA.
- The company confirms, the operator checks in on arrival, and the platform records the confirmed bonus.
Architecture
A modular monolith: FastAPI with Pydantic v2 and SQLAlchemy 2 over PostgreSQL with PostGIS for radius checks, Alembic migrations, and a React PWA for operators plus an admin verification UI. No microservices, no queues, no ML matching.
Product rules live in a project context document and ADRs. A separate implementation-status file records, per capability, what is designed, migrated, exposed, rendered, tested, and pilot-ready, so the README never overstates what works.
What I learned
Explainability is a data-model decision. Persisting ineligibility reasons costs little and answers most disputes.
A status table derived from code is the only honest roadmap.