LogiDOC
One platform for transport and document management
A transport management platform built from real operational pain, validated with three logistics companies across Europe.
Adrian Burlău — Product Designer
Adrian Burlău — Product Designer
Every transport generates a paper trail no one owns
Every transport generates a paper trail: CMRs, invoices, customs declarations, delivery confirmations. In most mid-size logistics operations, that trail lives across email inboxes, WhatsApp threads, and local folders. When something goes wrong, finding what you need is manual, stressful, and slow.
LogiDOC consolidates transport management, document handling, and carrier coordination into one place. Built for teams that have outgrown scattered tools but don't need a full enterprise TMS.
The documents are unmanaged, even when the process isn't
Logistics teams manage complexity through documents, but the documents themselves are unmanaged.
Local folders
Carriers communicate by WhatsApp, confirmations arrive by email, status updates are ad hoc. Nobody has a single view of a transport and everything attached to it.
The result is operational risk that compounds quietly until it becomes very visible.
A focused alternative to logistics chaos
Logistics is still running on tools that haven't caught up. Contracts get shared over email, confirmations happen over WhatsApp, documents live wherever they were last saved and this isn't a small operator problem, it's how a large share of the industry actually works.
The idea started close to home. My dad runs a truck transport business and I watched him lose track of documents constantly, sent somewhere, buried in an inbox, impossible to find weeks later when it mattered.
A full enterprise TMS is overkill for operators this size. The opportunity was building something focused enough to actually get adopted, not chasing buyers who already have a solution, however clunky.
One core loop, built to grow outward
Create a transport, assign a carrier, collect and track the required documents, with everything tied to that transport visible in one place.
Creating and assigning a transport
Route, cargo, and required documents get defined in one guided flow, the same information that used to live across a phone call, an email, and a spreadsheet.
Carriers, added once, reused everywhere
Adding a carrier is separate from assigning one to a transport, carriers get added to a shared list once, so future transports don't mean re-entering the same details. An invitation to create a full LogiDOC account can go out at that point, or later, independent of whether they've been assigned anything yet.
A transport's full timeline in one view
Every transport carries its route, cargo specs, carrier and driver details, and a live timeline of every status change, from created, to in-transit, to delivered, in a single page instead of pieced together from separate threads.
Docs, versioned and reviewed in place
Every required document: CMR insurance, transport licenses, registrations, gets uploaded, versioned, and approved or rejected without leaving the platform. Old versions stay on record instead of disappearing into an email thread.
Same problem, different intensity
I validated the problem with three logistics companies varying significantly in scale, from a large pan-European operator down to a smaller structured company that works directly with our family business.
Pan-European operator
Same fragmented communication and manual document handling at a scale where the risk compounds faster.
Structured regional operator
Same core issues, less institutional process around them to absorb the impact.
Family-adjacent operator
The clearest version of the problem documents lost between a phone, an inbox, and memory.
The findings were consistent across all three: fragmented communication, unreliable document access, manual processes. What differed was intensity, not nature. This confirmed both the problem and the decision to stay focused: solve the immediate, high-impact issues first, and defer everything else.
Per week a dispatcher spends manually tracking down transport documents across email, WhatsApp, and folders, based on interview walkthroughs at all 3 companies.
Transports where a required document had to be re-requested from a carrier because the original was lost or unfindable when it was actually needed.
Of carriers said they'd delay or skip signing up for a new platform outright if it required creating an account before they could act, a direct input into the no-account portal decision.
Why the activity panel shipped first
GPS tracking was the obvious answer for real-time visibility: a live map, a route from A to B. But it only tells you where the truck is, not what's actually happening: whether loading finished, whether a delay is at the warehouse or on the road.
The activity panel does that with human input instead of hardware: someone at the warehouse marks loading complete, a carrier updates status manually if they choose to. It works with or without GPS, ships without any tracking-hardware dependency, and covers milestones GPS never would on its own.
GPS stays on the roadmap, paired with the activity panel later, not replacing it.
Problem
As a self-directed concept project, I didn't have a research team or an engineering team, so research and build both fell to me. I split research into two tracks: AI-assisted research for general industry data, standards and context, and direct interviews with three European logistics companies to understand real day-to-day behavior, the parts no industry report captures.
AI tools used
For the vibe-coded prototype being built, I used VS Code with Claude Code, and Supabase for database and auth, with more tools being added as development continues.
Judgement calls
AI accelerated the mechanical layer by synthesizing industry research and scaffolding the app, but the main product decisions came from the interviews. It's still in progress, working to bring it to a public interactive preview.
Trade-offs made along the way
Focused core over broad platform
The research surfaced tempting directions: factory integrations, bulk scheduling, automated routing. All deferred to a focused core product: transport management, documents, carrier coordination, this delivers clear value and scales outward from there.
Choosing what not to build shaped the product as much as anything else.
Carrier portal: no account required
Every company interviewed struggled with carrier coordination. Requiring an account was the initial assumption, until conversations surfaced that other contract-signing tools had lost clients exactly that way: carriers abandoning a transport rather than create an account first. A platform carriers have to join before they can act is a platform most carriers will ignore.
Account required
Full signup before a carrier can view or act on a transport.
Optional, token-link
Act instantly via a secure link. Account available, never required.
Shareable link: channel-agnostic entry point
Logistics coordination happens on WhatsApp as much as email, especially for spot-market bookings. Every transport generates a shareable link that works anywhere, the flow is identical either way. The difference is removing a channel switch at the moment speed matters most.
Optional full account for carriers
The default asks nothing, but a full account is available for carriers who want one: documents kept on file, fleet management, faster acceptance on future transports. Same no-friction principle as the token-link portal, just for the carriers ready to go further.
What didn't make it through and what still doesn't hold up perfectly
Some carriers simply won't adopt a new platform. The designed solution is an AI agent that reaches out to unresponsive carriers via email or WhatsApp, channels they already use. The carrier responds however they normally would: the agent parses the response and maps everything back into the platform automatically. Concept is defined, implementation isn't built yet.
I'm not a backend engineer, so the design stays close to what I can actually build myself with Claude Code, Supabase, and other third-party services, not the ideal scope, the honest one. GPS tracking, invoicing and warehouse APIs would strengthen the product, but they're held back deliberately until they're buildable, not just designable.
This is a first version built from limited knowledge, not the full day-to-day reality of how these companies operate. I haven't sat with them long enough yet to catch documents or exceptions I'm not even thinking about, closing that gap is exactly what the planned business trip with two of the three companies is for.
A focused product isn't a limited one, it's a positioned one
Understanding logistics from the inside meant better questions and faster pattern recognition, the discipline was separating personal familiarity from what the product actually needed.
This started as a design exercise and became something I believe could ship.
That shift changed how every decision was made.