• Software comparison
• Route Planning

Vibecoding Your Own POD App: What the Weekend Demo Leaves Out

Why pay for delivery software every month when an AI assistant can write the same app over a weekend? More operations teams are asking that question, and it deserves a straight answer. AI coding tools are genuinely good now. Within a few days, someone working with Cursor or Claude can have a driver app that takes photos, collects signatures and scans barcodes, and the demo will look convincing.

The demo, though, was always the cheap part of a proof of delivery system. Whether a home-built tool survives its first year depends on what sits underneath it. That means the routing maths, the map data and the constant stream of driver locations. It means the personal data you become legally responsible for. And it means the release process that stops one fix from breaking three other things.

We asked Vladimir Petrushka, Track-POD's Product Owner, where those costs land. This piece goes through his answers and the research behind them. It ends with five questions that show whether building your own is realistic for your operation.

What AI genuinely does well

AI handles best the parts of a POD app that a driver actually touches. Credit where it's due:

• Driver screens: the stop list, order details, and the Delivered and Failed buttons.
• Photo capture and e-signature. Phone cameras and standard libraries do most of the work.
• Barcode and QR scanning. "Scanning is not hard," the PO told us, and he's right. Open-source scanning libraries are mature, and Track-POD provides its own free barcode scanner for the same reason.
• Simple admin pages, such as a CSV order import and a list of today's deliveries.

A delivery operation doesn't pay for any of this, though. A Delivered button is only worth as much as the system that records the delivery, routes the next one and keeps that record safe. That system is where an AI-built tool starts to struggle.

Under the hood: four problems you can't prompt away

1. Route optimisation is a maths problem

Putting stops in order looks like a sorting job. It is actually the vehicle routing problem, which George Dantzig and John Ramser formalised in 1959. The problem is NP-hard, meaning no known method finds the best answer quickly for every case (IEEE).

For a single van, the number of possible stop orders grows factorially. Ten stops can be driven in 3,628,800 different sequences, fifteen stops in roughly 1.3 trillion, and twenty in more than two quintillion. Every real constraint multiplies that further: a second vehicle, delivery windows, van capacity, driver breaks, a customer who only accepts goods before 10 a.m.

Production routing engines handle this with heuristics tuned over years of real routes. An AI assistant will gladly write a loop that sends each van to the nearest unvisited stop, and it will produce a route. Whether that route is good is a different question, and often nobody on the team can tell.

In practice, home-built tools end up renting a solver. Google's Route Optimization API, for example, bills for every shipment in every request, at one rate for single-vehicle routing and a separate rate for fleet routing. The PO puts it plainly: optimisation without paid services is close to impossible. Even with them, you still have to lay the result over a map, track it and show it to dispatch. "Build" turns into "build, then pay usage fees on every delivery." (Track-POD's own route planning is part of the subscription.)

2. Maps go out of date

A map is a snapshot of a street network that never stops changing. New housing estates go up, one-way systems get introduced, bridges close, low-emission zones expand, and a customer's goods-in entrance moves round the corner. OpenStreetMap alone logged roughly four million map changes a day in late 2021.

"If you take a map once, there's no guarantee it won't be a completely different map two years later," the PO said. So a delivery tool needs a map source that is maintained, licensed and paid for, and a routing engine that reads the current version of it. A dataset downloaded once at the start of the project starts going stale the same day.

3. Getting GPS is easy. Storing it is the system

Reading coordinates from a phone takes a few lines of code. The PO's point was that coordinates are useless unless you store them, display them and keep their history, and that is where the real engineering lives.

Each driver's phone reports its position every few seconds, all day. Take a modest example: 40 vans pinging every 5 seconds over a 10-hour shift generate 288,000 location points a day. Across 250 working days that comes to 72 million rows, and you need them for ETAs, disputes and driver reports. At Track-POD, the database handles around 60,000 requests per second, most of them driver positions. A system under that kind of load has to be monitored, scaled and paid for around the clock, and somebody has to own it.

4. Offline is where demos break

Drivers deliver to basements, loading bays, industrial estates and rural roads with no signal. A usable POD app has to keep working there. It records the photo, the signature and the scan, queues them on the phone, and syncs once the signal is back, without losing or duplicating anything.

The hard part is conflict. Suppose a dispatcher edits an order while the driver is offline, and the driver then completes the old version. Which one wins, and who finds out? The PO counts a dependable offline mode among the things AI-generated apps don't get right. It's also difficult to test, because everything works perfectly on the office Wi-Fi.

The hidden stones

Every fix breaks something else

"A badly written program doesn't scale," the PO said. "You fix one thing and break another, and the bugs never end." Track-POD's safeguard is its development process: every release is checked against what already works before it ships. A tool assembled by prompting rarely has anything like that, and each change gets riskier as the code grows.

The speed AI seems to add is also smaller than it feels. In METR's randomised trial, 16 experienced developers completed 246 real tasks in mature codebases they knew well. With AI tools allowed, they took 19% longer. Before starting, they had expected to be 24% faster, and afterwards they still believed they had been about 20% faster. The researchers note the result applies to experienced people working on large, mature projects. After a year in production, a delivery tool is exactly that kind of project.

Code that runs is not the same as code that's secure

Veracode tests AI models on coding tasks with known security pitfalls. Its 2026 report found that across more than 100 models, the average security pass rate is still about 56%, barely changed from the year before, even though the generated code almost always compiles. Models built specifically for coding did no better than general-purpose ones. This is one vendor's benchmark, not a measure of every codebase, but the pattern holds: the app runs, and nobody has checked what it exposes.

Personal data you're now responsible for

A POD system holds customer names, addresses, phone numbers, signatures and doorstep photos, plus a minute-by-minute record of where every driver has been.

"People don't think about this," the PO said. "They think storing a first name and surname in plain text is normal. It isn't."

GDPR Article 32 requires security appropriate to the risk, and it names pseudonymisation and encryption of personal data among the measures. Rules also vary by country, and you have to meet the ones that apply where you operate in full.

Driver tracking adds an employment layer on top. The UK ICO's guidance on monitoring workers covers location tracking in work vehicles. In short: tell drivers what is tracked and why, use the least intrusive method that does the job, and run a data protection impact assessment where the monitoring is high-risk.

Then comes the audit.

Larger shippers and retailers check their delivery partners' systems, and the PO's verdict on a home-built tool was short: "You won't pass the audit." Without access controls, logging and encryption at rest, the conversation ends there.

Lost data lands on finance

Delivery records are billing records. When POD data disappears, someone has to work out who received what, when, and what should have been invoiced.

"Accounting will eat you alive," the PO said, "because they have to restore everything."

Track-POD has seen this first-hand. An incident once took out a week of data, and rebuilding that week took two months of people's time. GDPR Article 32 also expects you to be able to restore access to personal data promptly after an incident. In practice that means backups that have been tested, and someone who knows how to use them.

Who can realistically build it

Some companies can build their own delivery software, and some do. In our experience, they have five things in common:

1. A standing engineering team, not one enthusiastic person. The tool will need maintaining long after whoever prompted the first version has moved on to other work.
2. Someone who owns infrastructure and on-call. Location data and offline sync run all day, every day, including when the route planner breaks at 5:30 a.m.
3. A budget line for maps and routing, one that grows with every shipment you plan.
4. A compliance owner who can answer an auditor's questions about encryption, access and data retention.
5. A reason the software sets them apart. When the way you deliver is the product you sell, owning the code can be worth it.

Companies that tick all five boxes tend to be large, and in the PO's experience large corporations rarely go down this road anyway. For a mid-size operation, building doesn't remove the subscription. It turns it into salaries, cloud bills and API invoices, and leaves day-to-day deliveries resting on code that one or two people understand.

Five questions to answer before you build

1. Who fixes it at 6 a.m. when drivers can't log in?
2. Which routing engine will you use, and what will it cost per shipment at your volume?
3. Where will driver locations be stored, for how long, and who can see them?
4. Can you show an auditor that customer data is encrypted and that access is logged?
5. If last week's delivery records disappeared, how would finance rebuild them?

If each answer has a name and a budget next to it, building may be a real option. If some of them don't, those are the gaps a delivery management platform already covers. Track-POD includes route optimisation, live tracking, an offline-capable driver app, load confirmation and proof of delivery records with access control and history, all maintained by a team that does nothing else.