The workflow came before the software
Working in foreign trade sales changes how I look at internal tools. A screen can be polished and still fail if it does not match the way an inquiry becomes an order, how an order reaches packing, or how management later checks performance and cost.
TradeFlow started from small, repeated moments: the same customer information copied into several places, product data changing between a quotation and a PI, packing details arriving late, and performance numbers being rebuilt after the work was already finished. Each problem looked minor in isolation. Together they created delay, uncertainty and avoidable rework.
Map the handoffs, not only the pages
The useful unit of design was not a page. It was a handoff between people and responsibilities. Sales needs to know whether an inquiry is worth following. Operations needs complete order information. Packing needs the exact products, quantities and carton rules. Management needs numbers that can be traced back to real orders.
- Inquiry data should become an opportunity without being retyped.
- An accepted quotation should carry forward into order and PI data.
- Packing, inventory, logistics and customs should use the same product facts.
- Performance and payroll should be derived from business records, not rebuilt separately.
AI belongs inside a verified workflow
AI is useful when it reduces a concrete step: drafting an inquiry reply, summarizing business data or helping research a market. It is less useful when it becomes a separate chat window with no connection to permissions, records or follow-up actions. In TradeFlow, the goal is to place AI beside the workflow while keeping important writes reviewable and business rules deterministic.
What I learned from shipping it
A production system teaches different lessons from a prototype. Data migrations need backups. A convenient field can become a contract used by several modules. Mobile users expose interaction problems that a desktop test never shows. The fastest improvement is often not a new feature, but removing a duplicate request, a slow page transition or an ambiguous status.
The most important result is not the number of screens. It is that a real team can use one connected flow and that the system can keep improving without losing trust in its data.
What the latest audit changed
The current system is private and the old public prototype link no longer represents it, so I removed that link instead of sending readers to the wrong repository. A fresh server test run passed 211 of 234 tests; all 23 remaining failures are in one management integration suite and point to authorization-fixture isolation. The code audit also identified raw SQL execution, SQL and parameter logging, large service modules and extensive legacy typing debt. These do not erase the product value, but they define the next reliability roadmap: query isolation, log redaction, test determinism and module boundaries before more surface area.