The transport industry still runs on Excel, paper notes, and WhatsApp messages. The driver leaves in the morning without a precise list of jobs, the customer calls about delivery times, and the bookkeeper writes invoices by hand from an Excel printout. With five drivers and a hundred orders a week, the system doesn't scale — it collapses quietly into wrong decisions and forgotten invoices.
This is a case study about building a logistics app for a transport company in North Savo, Finland, during spring 2026.
The partner's situation
Orders came in by phone and email. The dispatcher wrote them in Excel, called the drivers, sent the route map on WhatsApp. The driver did the run and brought a paper slip back to the office. Bookkeeping waited a week until the slip surfaced from the pile. The invoice was typed into Fennoa by hand, customer details copy-pasted.
Time was lost at every step, and an error was possible at every step. The customer couldn't see where their order was. The dispatcher couldn't see which jobs hadn't been logged. The driver couldn't see tomorrow's calendar. The owner couldn't see the margin on a single job before the invoice was out the door.
Decision: off-the-shelf or custom?
There are SaaS products for logistics. Most are good — if your processes match the product's defaults. Transport is fragmented, and every operator has their own way of dispatching, pricing, and logging. An off-the-shelf tool forces you to change the process, when the people have already done it a thousand times their own way.
Three starting points:
- Custom takes more upfront, but day-to-day the tool fits the process — not the other way around.
- Fennoa integration was non-negotiable. The owner did not want to switch accounting systems.
- Permissions had to be role-specific: driver sees only their own jobs, customer only their own orders, dispatcher the whole picture, admin also the price table and user management.
No single SaaS product covered all three at once. Custom was the only path that worked.
Tech choices and why
The stack is deliberately straightforward — a one-person operation can't sustain five exciting new technologies per layer.
Frontend: React 19 + TypeScript + Tailwind CSS 4, built with Vite. React is the most common web frontend stack right now, and TypeScript catches errors at compile time instead of revealing them on the driver's tablet at 6 AM.
Backend and database: Supabase. One package containing a Postgres database, authentication (including TOTP-based two-factor login), real-time state changes, and Edge Functions on Deno. The alternative was a custom Node.js backend, but that would have meant dozens of additional components to maintain with no equivalent benefit.
Security architecture: Row Level Security (RLS) in Postgres. Permissions don't live in application code at the "if user.role === 'driver'..." level — they live in database policies. Even if the browser code were broken open, or someone tried a direct API query, the database doesn't return rows the user has no right to. This is a significant security upgrade compared to frontend-only restrictions.
Hosting and communications: Vercel (frontend), Supabase (backend), Resend (email), Twilio (SMS). All of them are external services the owner pays for directly by usage — no middlemen, no monthly contracts to administer.
Accounting integration: Fennoa REST API. Customer accounts sync, an invoice is created when the dispatcher approves a work log. Token settings are stored encrypted in the database, and the actual Fennoa call happens in a server-side Edge Function — the browser never sees the accounting credentials.
Critical implementation decisions
Mobile-first for drivers
The driver uses the app from the cab, mostly on a 10-inch tablet. The UI was built mobile-first: buttons hit with a finger, forms complete in one round, and the driver doesn't need a keyboard to update a job. The office UI uses the same components but in a wider layout on a larger screen.
Roles and views, separated
The app has five roles: admin, dispatcher, customer, driver, subcontractor. Each role unlocks different tabs in the bottom navigation. The customer sees Orders and Company. The driver sees Logs and Worktime. The dispatcher sees the Panel and Calendar. One role's tasks don't leak into another role's view — clean surface, less learning per user.
Audit log for everything that changes
When an invoice goes out to Fennoa, when a log is changed, when a user is created or removed — every event lands in an audit log. Required both for the company's own traceability and for GDPR. The log can't be modified through the application after the fact.
Soft delete + 30-day recovery window
An order or log isn't permanently deleted with one click. A deleted row is marked deleted, kept for 30 days, and can be restored from the Archive tab. This is a direct response to "I clicked the wrong thing." The cost of human error is minutes, not days.
Two-factor authentication for admins
Admin and dispatcher roles require TOTP-based two-factor login (Google Authenticator or equivalent). Customer and driver roles can opt in. The EU NIS2 directive comes into force for SMBs during 2026 — compliance was built in, not glued on after the fact.
What the partner gets
The order kanban view replaced Excel. The dispatcher drags a driver onto a job, the driver sees the new job in their calendar immediately, the customer gets an automatic email notification of delivery progress. When the driver marks a job logged, the dispatcher gets a notification, and one approval click sends the invoice to Fennoa.
Concretely:
- Order lead time: when the dispatcher approves a log, the invoice goes to Fennoa in seconds — not a week later, chasing paper slips.
- Customer communication: the customer sees the order status themselves; "where is my shipment" questions get answered by the system, not by a phone call.
- Data integrity: Excel copy-paste errors disappear when data flows directly from log to invoice.
- Scalability: the same process holds for five or fifty drivers — no manual administration scaling alongside.
The partner owns the software
The flip side of any SaaS purchase is the monthly bill — as long as you pay, the tool runs. Stop paying, the tool stops. A custom application is a different category: the partner owns the source code, the documentation, the database, and all the external service accounts (Supabase, Vercel, Resend, Twilio). Operating costs go to hosting by usage, not to a licence.
This is especially valuable in an exit. When the company is sold a few years down the line, the buyer gets the cash flow plus a concrete asset — a working, documented piece of software that runs the entire operation. SaaS licences can't be sold, but owned software sits on the balance sheet and lifts the multiple on the sale price.
A well-documented system also means another developer (or the new owner) can pick up where the original builder left off. Lock-in to me is minimised by design: standard technologies (React, Postgres, Supabase, Vercel), an extensive docs folder (project plan, testing plan, rollout plan, security plan), and every database migration in version control. The business is not on my shoulders.
What this says more broadly
A one-person software shop wasn't possible five years ago. Building a serious logistics app required a team: backend developer, frontend developer, devops, designer, tester. Easily six months and hundreds of thousands of euros.
In 2026 the picture has changed. Supabase handles half of what used to be the backend team. Vercel handles devops. Tailwind handles styling. AI supports every stage, when used right. One person can deliver what previously needed five.
This doesn't mean every small software project should be built custom — off-the-shelf tools are often the right answer. But if your process is so home-grown that every SaaS forces you to change it, custom is now possible at a budget that would have been absurd five years ago.
Got a process that's all manual labor, and no off-the-shelf product fits it? Automation Kickstart begins with a mapping session: we identify the repetitive parts and figure out the most sensible path forward together.