Product case study · Building
A connected operations system for small and mid-sized transport and logistics businesses.
OpsFlow is designed to replace scattered Excel sheets, WhatsApp threads, notebooks and disconnected records with one connected operational workflow, from customer orders to trips, invoices, payments and outstanding balances.
The early build is a sign-in shell of the current software. Use synthetic data only.
The problem
Many small and mid-sized businesses may manage these workflows across a combination of spreadsheets, messaging and manual records. That can make it harder to keep one consistent view of customers, orders, trips, invoices, payments, outstanding balances and reports.
Who it is for: small and mid-sized transport, logistics, freight, warehousing and distribution businesses.
A typical pattern, not a claim about every business:
The value is not simply storing records. The product connects operational events so that information created in one part of the workflow can support the next.
Core workflow
Select a stage. Each shows its purpose, data, actions, related process and honest status.
Maintain the customer information used across the whole operational lifecycle.
Capture what the customer requested, so operations start from one agreed record.
Represent the actual operational execution of an order.
Convert completed operational work into a billing record.
Record payment received against business receivables.
Give visibility into unpaid balances.
Turn connected operational data into business information.
Current status
A working foundation and the first operational modules. The financial half of the workflow is still ahead.
A portfolio product project: the code is real and running, but it is not a released product and has no customers, revenue or usage figures. The list is checked against the current code.
Modules
Customer records, credit terms and contacts.
Fleet vehicles with ownership, odometer and service intervals.
Driver records with licence details.
Trailers, containers, equipment, maintenance, fuel and mileage logs.
Rate-card pricing, server-calculated totals and an approval workflow.
Contract and spot rates by customer, route and vehicle type.
Role-based permissions, owner protection, two-factor sign-in.
Branch records and branch-scoped access.
Organisation profile only; wider configuration is still ahead.
Approved quotations become orders. The next roadmap step.
Assigning vehicles and drivers and tracking execution.
Billing records created from completed work.
Payments recorded against invoices.
Unpaid balances and receivables.
Trip and operating expenses.
Operational and financial reporting.
Stock locations and movements.
API means the capability exists in the backend; UI means a screen exists in the current build. Most screens are still ahead.
Data relationships
Quotations (implemented) sit between customers and orders: an approved quotation is what becomes an order in the next step.
Product preview
| Recent activity | Customer | Stage |
|---|---|---|
| Order created | Demo Customer A | Order |
| Trip dispatched | Demo Customer B | Trip |
| Payment recorded | Demo Customer C | Payment |
| Customer | Open invoices | Status |
|---|---|---|
| Demo Customer A | 2 | Due soon |
| Demo Customer B | 1 | Current |
| Demo Customer C | 3 | Overdue |
Multi-tenant architecture
The product is designed around company-level data isolation, so several businesses can use the same application without mixing operational records.
●Implemented Implemented in the foundation and the existing modules: every tenant record carries an organisation id, tenant identity comes only from the signed-in session, queries are scoped to it, and composite foreign keys enforce it in the database. An end-to-end test suite exercises it. Modules still to be built will follow the same rule.
Product thinking
Each began with one specific operational problem: a billing calculation, a vehicle balance, an overtime bill. They solve that workflow directly.
Instead of one port workflow, it models the patterns that recur across transport and logistics businesses: customers, orders, trips, invoices and payments.
An exercise in product design and building. The source is private and there has been no market validation.
Architecture and technology
The source repository is private. No microservices, queues or container orchestration are used.
Why it exists
After working with real operational workflows, I saw how much business information can become fragmented when orders, operations, billing and payments are managed separately. OpsFlow is my attempt to turn that understanding into a reusable product for businesses with similar operational complexity.
These are design principles, not claims about results. There has been no market validation.
AI-assisted development
AI helps accelerate implementation, exploration and debugging. The product requirements, operational model, business rules, validation and final decisions remain directed by me.
Roadmap
Categories, not dates. “Future” means an idea worth exploring, not a commitment. Settings covers the organisation profile only, and audit history is stored but has no screen yet.
Explore
The current software, as it stands. It is early, and it is real.
View OpsFlow early build ↗If your business still relies on disconnected spreadsheets, manual records or repetitive operational workflows, I'd be interested in understanding the process and exploring what could be automated.
Discuss an operational problem