TL;DR
- Scenario: a 35-person UK freight and logistics company (hypothetical) running entirely on 14 operational spreadsheets
- Problems: data silos, version conflicts, manual reconciliation, inability to scale, no real-time visibility
- Build: a custom operations platform with job management, a customer portal, a driver app, Xero integration and automated notifications
- Tech stack: Python FastAPI + React + PostgreSQL + n8n, hosted on Google Cloud Run
- Typical timeline: a 4-month build and an 8-week phased rollout
- Aim: much less operations admin, and room to take on more work without adding admin headcount
The Starting Point: 14 Spreadsheets, One Business
In this illustrative example, the company is a 35-person freight and logistics firm based in the Midlands, specialising in time-critical B2B freight movements across the UK. It has been operating for 12 years and has grown organically from a 5-person operation to a team of 35, but the systems that served it at five people are still in use at 35.
Its operation runs on 14 spreadsheets:
- Quote Tracker: All active and historical quotes, with status, value, customer, and assigned operations contact
- Job Schedule (current week): All active jobs for the week, with collection and delivery details, driver assigned, and status
- Job Schedule (next week): A separate sheet because the current week sheet would get too large
- Driver Allocation: Which driver is on which job, their availability, and hours tracking
- Subcontractor Register: Third-party hauliers used for overflow capacity, with rates and availability notes
- Customer Contact List: Key contacts at each customer, updated manually by different team members
- Pricing Matrix: Rate cards by lane, weight, and customer tier
- Invoice Tracker: Jobs that had been invoiced, payment status, and outstanding amounts
- POD (Proof of Delivery) Log: Tracking which jobs had PODs received and filed
- Vehicle Maintenance Log: MOT dates, service due dates, and defect records for the fleet
- Driver Compliance: Licence expiry, CPC training, digital tachograph records
- Claims Register: Damage and loss claims with status and financial impact
- Customer Reporting: Monthly usage and performance stats compiled manually for each major customer
- Monthly KPI Sheet: Manually compiled management reporting (revenue, volumes, margins, on-time performance)
Each spreadsheet is kept in a shared folder and several people edit them at the same time. Google Sheets can handle this to a point, but it causes constant conflicts when two operations coordinators update job status at once. The job schedule sheets are the worst: by Thursday of each week, the current week sheet is an unnavigable mass of highlighted cells, crossed-out entries and manual notes in cells.
The Problems These Spreadsheets Created
Data Silos
A customer job exists in the quote tracker, the job schedule, the invoice tracker and the POD log: four separate entries maintained by four different people. When the customer rings to ask about their delivery, no single person can answer without checking several sheets.
Version Conflicts
The pricing matrix gets edited by the MD without the operations team being told, so jobs can be quoted at old rates for weeks before anyone notices. The invoice tracker and the accounting system drift apart every month and need a two-day reconciliation exercise.
Manual Reconciliation
Friday afternoon reconciliation compares the job schedule with the invoice tracker, the driver allocation and the POD log. In this scenario it takes around five hours a week across two people. Every discrepancy needs individual investigation, and month-end reconciliation is a two-day exercise.
Inability to Scale
A business in this position may turn down major contract opportunities because "the team doesn't have capacity." The real constraint is not drivers or vehicles; it is operations administration. Every additional job adds administrative overhead that the team cannot absorb.
What Gets Built: The Custom Operations Platform
A two-week discovery process (interviews with each team member, process mapping and a review of the spreadsheets) defines the scope for the custom platform around four core modules:
Module 1: Job Management System
The core of the platform. A single record for each job contains:
- Customer and contact details
- Collection and delivery addresses and windows
- Weight, dimensions, and special requirements
- Status (quoted → confirmed → scheduled → in transit → delivered → invoiced → paid)
- Driver and vehicle assigned
- POD status and document storage
- Real-time timeline of all status changes
The job board view replaces all three scheduling spreadsheets. It is a Kanban-style view showing all jobs by status, colour-coded by priority, with drag-and-drop status updates. Operations coordinators can see the entire week's work in a single view that updates in real time.
Module 2: Customer Portal
A login-protected web portal for the company's 12 regular customers. Each customer can:
- View all their jobs and current status in real time
- Download PODs without ringing the office
- Access their invoice history
- Request new quotes via a structured form
Aim: fewer inbound customer calls. In a business like this, many calls are status enquiries that interrupt the operations team; the portal gives customers self-service visibility instead of waiting on hold.
Module 3: Driver Mobile App
A React Native mobile application for drivers. Each driver's daily job list populates automatically from the job management system. Drivers can:
- View job details (addresses, contacts, special instructions)
- Update job status (collected, delivered, failed delivery)
- Capture and upload POD photos
- Report vehicle defects
When a driver marks a job as delivered and uploads the POD photo, four things happen automatically, with no operations team involvement:
- The job record in the main system updates
- The customer portal reflects the delivery
- The customer receives an automated email notification
- The job moves to the invoicing queue
Module 4: Xero Integration and Automated Invoicing
When a job moves to the "delivered" status, the platform automatically creates a draft invoice in Xero, using the agreed rate for that customer and job type. The operations coordinator reviews and approves the draft instead of creating each invoice by hand. Xero then handles payment tracking, reminders and reconciliation.
Aim: retire the invoice tracker spreadsheet entirely, and turn the two-day monthly reconciliation into a review of an automated reconciliation report.
Technology Stack
Backend API
Python FastAPI
REST API with async support, Pydantic validation, automatic OpenAPI documentation
Frontend
React + TypeScript
Web application with TanStack Query for data fetching, React Router, Tailwind CSS
Mobile App
React Native
iOS and Android driver app sharing component library with web frontend
Database
PostgreSQL
Managed Cloud SQL instance on Google Cloud, with read replicas for reporting queries
Automation
n8n (self-hosted)
Webhook-triggered workflows for notifications, Xero API calls, customer email and WhatsApp updates
Hosting
Google Cloud Run
Serverless containers, auto-scaling to zero, low-cost for the usage pattern
File Storage
Google Cloud Storage
POD images, documents, and attachments with signed URL access control
Accounting Integration
Xero API
OAuth 2.0 connection, automated invoice creation and reconciliation via n8n webhooks
A Typical Build and Rollout Timeline
In this example the project runs over about six months in total: four months of build and two months of phased rollout.
Weeks 1 to 2Discovery and Requirements
Interviews with all stakeholders, process mapping for each spreadsheet, data model design, wireframes for all key screens, technical architecture decisions, and project plan. Deliverable: a requirements specification document signed off by the MD and operations manager.
Weeks 3 to 8Core Platform Build
Database schema, FastAPI backend, React web frontend (job management module first, then customer management and invoicing queue). Weekly demos to the client for feedback. A few operations staff test the job management module from Week 6, and the issues they find are fixed before broader rollout.
Weeks 9 to 14Portal, Mobile App, and Integrations
Customer portal, React Native driver app, Xero API integration, n8n automation workflows (delivery notifications, POD emails, invoice creation triggers, payment reminder triggers). Data migration: 18 months of historical job data migrated to the new database for reporting continuity.
Weeks 15 to 16Phase 1 Rollout: Operations Team
Operations coordinators trained and transitioned to the new system. Job schedules run from the platform; spreadsheet kept as read-only backup for the first two weeks. Expect a batch of small issues in the first week (mostly UX preferences and minor data display issues), fixed as they come in.
Weeks 17 to 18Phase 2 Rollout: Drivers
Driver app rolled out to all 14 drivers, with individual support sessions for anyone less comfortable with the app. Paper job sheets kept for the first week as a backup, then retired once drivers have stopped using them.
Weeks 19 to 22Phase 3 Rollout: Customers and Finance
Customer portal launched to the 12 regular customers with a personal introduction email from the MD. Xero integration activated; automated invoicing live. Finance team trained on the reconciliation report. All 14 spreadsheets archived (read-only) once the first clean month-end reconciliation has been completed on the platform.
What the Build Aims For
| Typical problem | What the build aims for |
|---|---|
| Operations admin taking many hours each week | Much less admin time, with routine updates handled by the platform |
| Frequent customer calls asking for job status | Fewer status calls, because customers can check the portal |
| Month-end reconciliation taking two days | Reconciliation becomes a review of an automated report |
| Growth limited by operations administration | Room to take on more work without adding admin headcount |
| Customers waiting on hold for updates | A better customer experience through self-service visibility |
Design Lessons in This Example
- Discovery is worth doing properly. A two-week discovery phase adds upfront time and cost but helps prevent scope changes during build. Change requests that arrive during build tend to come from things discovery did not cover, and they are easier to handle when the underlying architecture is designed with change in mind.
- Get end users testing early. Operations coordinators who test the job management module early find issues a development team would miss, because they test with real scenarios from their working day. Their feedback improves the product before it goes near a customer.
- Phased rollouts matter for operations systems. Running the platform and the spreadsheets in parallel for two weeks can feel inefficient, but it provides a safety net against business disruption, and issues found during parallel running are far easier to fix then.
- The driver app is easy to underestimate. React Native development across iOS and Android adds complexity, and device-specific bugs on older Android models can take extra time. A budget contingency (for example, 15% of project cost) helps absorb this.
- The biggest benefit may not be the one you expect. It is natural to expect the main benefit to be less administration time. In a business like this, the bigger opportunity is often the ability to take on more work without more headcount, by removing the operational bottleneck. Owners often have not connected the spreadsheet problem to the growth constraint until discovery points it out.
When Does Excel Stop Being Enough?
Excel and Google Sheets are genuinely powerful tools. They are flexible, accessible, and require no technical expertise to use. The question is not whether spreadsheets are good. It is whether they are still the right tool for the job at your current scale and complexity.
The tipping point comes when one or more of these conditions are true:
- Multiple people need to edit the same data simultaneously and conflicts are causing errors
- Data in the spreadsheet needs to be available in real time to people who are not at a computer (drivers, field staff, customers)
- The spreadsheet has become the only way to run a process, and the person who maintains it is a single point of failure
- You are spending significant staff hours each week maintaining, reconciling, or correcting the spreadsheet rather than using the data in it
- The spreadsheet cannot do something the business needs, such as sending an automated notification, integrating with an accounting system or showing a customer their current status
- The business could grow faster if the operational process the spreadsheet manages could handle more volume
If two or more of these apply, it is worth weighing the cost of custom software against the staff time and errors the spreadsheets cost you. Often the question is not whether to build. It is what to build, in what order, and how to phase it to minimise risk.
Running Your Business on Spreadsheets?
SpiderHunts Technologies builds custom operations platforms for businesses that have outgrown their spreadsheets. We handle everything from discovery and design through build, data migration, and rollout. If your operations are constrained by manual processes and disconnected data, let us show you what is possible.
Get a Free Discovery Call