Autro
A trade operations system for a Spanish exporter of recycled polymers. Hussain wrote its requirements, then rebuilt it — twice.
Business Analyst & Full Stack Developer · TRICYCLE PRODUCTOS SL · 2023 – 2026
autro-tricycle.tech- trade operations
- 64trade operations
- document types generated
- 13document types generated
- countries traded with
- 8countries traded with
- months in production
- 12+months in production
The problem
TRICYCLE buys recycled polymer from suppliers across Spain and sells it to buyers in Turkey, Vietnam, Germany, Hong Kong and elsewhere. Every shipment carries a purchase contract, a sale contract, containers, costs in two currencies, and a stack of export paperwork: a bill of lading, a certificate of origin, a phytosanitary certificate, a fumigation certificate, an EUR.1.
All of it lived in spreadsheets and a few disconnected tools. Nobody could say what a shipment had earned until it was over, and preparing one container's documents meant hours of copying the same figures between files.
What made it hard
The hard part was never the paperwork. It was that a shipment is not one thing.
One purchase can feed several sales. One sale can draw on several purchases. A single operation can carry twenty containers, each with its own weight, its own price and its own currency. Profit is only real once every cost has landed against the right container — transport, customs, insurance, loading, certification, brokerage, storage, bank fees.
A spreadsheet can hold all of that. It cannot enforce any of it.
The decisions
Model the operation, not the paperwork
The centre of the system is the operation: a shipment with its parties, containers, costs and contracts. Documents are generated from it. That is why one click produces thirteen document types instead of thirteen templates that each have to be filled in by hand.
Define the lifecycle clearly
An operation moves through eight states: draft, confirmed, loaded, in transit, arrived, delivered, completed, cancelled. Invoices, contracts, payments and documents each have their own lifecycle. Writing these states and transitions into the requirements document before any code existed kept the rules from being reinvented screen by screen.
Store the exchange rate with each record
Prices are quoted in euros and dollars, using the rate from the day of the transaction. Storing that rate with each record, rather than converting when someone opens a report, means last year's profit does not change when today's exchange rate does.
Rebuild rather than patch
Version one was built with Flutter and Laravel by a team of five, connected to the WhatsApp Business API, and it worked. But the domain model was discovered during development rather than defined beforehand. Hussain then wrote the requirements in full — domain model, state machines and business rules — and rebuilt the system end to end with React, TypeScript, tRPC, Drizzle and MariaDB.
What changed
The system replaced the spreadsheets and has run in production for over a year. Document preparation went from hours to minutes. Net profit, margin and profit per ton are visible while the shipment is still moving, rather than after it closes.
It now holds 64 trade operations, 36 of them completed, with counterparties in eight countries, invoiced in euros and dollars, under role-based access with a full audit trail.
What it taught him
The requirements document was not overhead. Every hour spent defining the domain model before the rebuild came back as a week not spent arguing about what a container costs, or which of two screens was telling the truth.
Building what he had specified changed how Hussain writes requirements. A rule that turns out to be difficult to implement is usually a rule that was described too loosely.