A SaaS Dashboard for a Logistics Startup: Real-Time Fleet Tracking on a Lean AWS Bill

A logistics startup in Surat moves cotton bales from Gujarat ginning mills to Mumbai ports and Bhiwandi warehouses. 200 trucks, each pinging GPS coordinates every 15 seconds. The founder wanted a real-time fleet dashboard — and a firm ceiling on the monthly AWS bill. We shipped under it. Here is the architecture, the cost breakdown as an SVG, and the 4 optimisations that cut 60% from our first estimate.

The Answer in 60 Words

200 trucks → MQTT to AWS IoT Core → IoT Rule batches every 10 pings → Lambda writes 100-record bundles to Amazon Timestream → Next.js dashboard hits Timestream via API Gateway with 12-second cache. The dashboard renders 200 trucks on a map at sub-second latency. Cost scales linearly to ~600 trucks before re-architecture.

Why This Matters Now

Indian logistics startups are stuck between two cost tiers. The cheap path: "use Loconav, pay per truck per month, accept their data and their UI." The expensive path: "buy a custom Salesforce + Vehicle Tracking System solution." The middle path, build your own on AWS IoT Core + Timestream + a Next.js front-end, has become economically attractive since Timestream's pricing dropped in 2024 and IoT Core simplified batching. We shipped at a 42% saving versus Loconav at this scale, with full UI control.

The Client (Specific Details)

The Architecture

The AWS Bill — Service Breakdown

The 4 Optimisations That Saved 60% From the First Estimate

Our first estimate was well over the target. The founder's reaction: "find another way." We did. Each of these is a specific change a reader can apply to their own AWS IoT build.

1. Batch writes to Timestream

Timestream charges per write operation, metered in 1 KB increments. A single GPS ping is ~120 bytes — but billed as 1 KB. At 200 trucks × 4 pings/min × 60 min × 24 hr × 30 days = 34.5M writes/month. At individual writes, you pay for every one of them just for the metering. We batch up to 100 records per WriteRecords call (the API max) — same data, one billed write per batch. Documented optimisation pattern, but we have seen 8 of 12 reference architectures online miss it.

2. Multi-measure records

Each truck ping has 5 dimensions we care about: lat, lng, speed, heading, engine-on. Old pattern: 5 separate rows per ping. New pattern: 1 row with 5 measures. Storage and query cost both drop 5x for the same data.

3. Aggressive memory→magnetic transition

Default memory retention is "however long you set it." We had it at 24 hours initially. The dashboard only ever queries the last 12 hours hot. We dropped memory retention to 12 hours; older data sits in magnetic store (~10x cheaper). For long-tail "where was my truck last Tuesday at 3pm" queries, magnetic latency (1–3 seconds) is acceptable.

4. Pre-aggregate the dashboard query

The dashboard fetches "all 200 trucks' last known position" every 12 seconds. Naive query: scan the last 30 seconds across all trucks. Optimised: a Lambda runs every 6 seconds, materialises the last-known position per truck to a small DynamoDB table, and the dashboard reads that. The expensive Timestream query runs 1x per 6 seconds across all users instead of N × per user.

The math from a first-pass estimate to the shipped bill:

Every line item fell. The "Other" line (Lambda, API GW, Mapbox, S3) mostly fell because we removed CloudWatch verbose logging once we trusted the system in week 8.

The Trade-Off We Made

Best practice for IoT data says "stream into Kinesis, then process." We did not. The reason: IoT Rules can route directly to Lambda for under 200 devices and the volume profile of 4 pings/min. Kinesis adds cost and 200 ms of latency for resilience we did not need. Above ~800 devices, we would add Kinesis. Below that, IoT Rules → Lambda is genuinely cheaper and not less reliable in practice. (Caveat: we lost 17 pings during a Lambda cold start in week 3. The map redrew them on the next ping. No buyer ever noticed.)

The Build (9 Weeks)

What the Founder Said

"The dashboard pays for itself the day a buyer calls me and I read out the truck's location on the screen instead of putting them on hold to ring the driver. That used to be once a week. Now it is once a day. I close more deals because I sound like I know what I am doing." We tracked: 7 of his 12 buyers said the live dashboard influenced renewal. A reader running similar shop can validate against r/aws discussions where Timestream + IoT cost questions appear constantly.

If you want a deeper take on the build-vs-buy reasoning behind a custom dashboard, our founder's blog at viveksinra.com has a longer write-up of the trade-offs from the founder's own perspective.

Loconav Comparison

The Loconav alternative we replaced: a per-truck monthly fee for the standard tier, plus a per-truck fee for "premium support." The custom build was a 57% saving at 200 trucks — recovered the build cost in 9 months. Where Loconav still wins:

For the founder, the deciding factor was custom integration with his Tally ERP — every trip closed in the dashboard auto-creates an entry in Tally. Loconav's API would have required costly integration work that custom-built avoided.

A Production Story From Week 11

In week 11 of operation, a truck went silent at 02:30 am. The dashboard's "last seen" indicator showed 47 minutes ago — flagged red. The founder was asleep; the ops staff on duty noticed. He rang the driver, who answered groggy: he had pulled over to sleep, the truck's accessory power had cut off, and the GPS device had stopped pinging. By 03:15 am, the driver was back on the road, the device was back online, and a buyer who would otherwise have been told a delayed-delivery story at 8 am was instead told the truck was on schedule. That single recovered shipment was a ₹2.8 lakh order. The dashboard's value is not always in the optimised metric — it is in the catch-the-anomaly-at-3-am moments that nothing else surfaces.

Common Mistakes

Symptom: "Timestream bill is double what we expected." Cause: not batching. Fix: batch up to 100 records per WriteRecords call.

Symptom: "Dashboard refreshes are slow." Cause: scanning Timestream from the browser. Fix: materialise to DynamoDB. Read DynamoDB from the dashboard.

Symptom: "Devices keep disconnecting." Cause: cellular signal in rural India is patchy. Fix: device firmware buffers pings locally, replays on reconnect. Don't expect zero loss.

Symptom: "MQTT certs are a nightmare to rotate." Cause: rolling 200 cert renewals manually. Fix: a Lambda-triggered cert renewal pipeline. We rotate annually; build the renewal pipeline before you launch, not after.

Symptom: "Driver privacy complaints." Cause: real ones. Fix: the dashboard shows truck location, not driver-mapped behaviour. We don't surface speeding events or harsh braking — those features were on the roadmap and we removed them after a drivers' union conversation.

When Not to Build This

Skip the custom build if (a) you operate under 80 trucks — Loconav's per-truck pricing is dramatically cheaper at that scale, (b) your routes are repetitive (factory → port → factory) and you do not need a live map, just an arrival ping — a Twilio SMS workflow is enough, or (c) you do not have one engineer who can stay on the system for ongoing operations.

The Cost-Optimisation Checklist (Save 50%+ On Your AWS IoT Bill)

• Batch writes to Timestream (up to 100 records per WriteRecords call)
• Use multi-measure records — one row with N measures, not N rows
• Drop memory retention to the lowest your dashboard actually needs (we use 12 hours)
• Pre-aggregate dashboard queries to DynamoDB; serve dashboard reads from there
• Disable verbose CloudWatch logging once the system is trusted (week 8+)
• Skip Kinesis below ~800 devices — IoT Rules → Lambda is cheaper
• Use Mumbai region (ap-south-1) for Indian devices to cut latency and cross-region transfer
• Build a cert-rotation pipeline before launch — annual rotation is unavoidable

FAQ

Can you run this on GCP instead of AWS?

Yes. Cloud IoT Core was retired in 2023, so you would use Pub/Sub + BigQuery + Cloud Run. Cost profile is comparable. We default to AWS because the Mumbai (ap-south-1) region has lower latency for Indian devices.

What is the cost at 500 trucks?

We modelled it. Linear scaling on writes and storage. At ~800 trucks, we'd add Kinesis between IoT Core and Lambda for resilience, which adds to the monthly bill.

Why Timestream and not InfluxDB / TimescaleDB?

InfluxDB self-hosted on EC2 is cheaper at scale (above 1,000 trucks) but requires you to manage uptime, replication, backups. Timestream is fully-managed. For a founder who does not have an ops team, the price difference is worth the operational simplicity. We have shipped TimescaleDB stacks for clients with dedicated SRE teams.

How accurate is the GPS?

Teltonika FMB920 with the Indian Jio M2M SIM gets 2–5 metres accuracy on the highway, 8–15 metres in dense urban areas. Good enough for "truck is at the port gate" but not for "truck is in dock 7 versus dock 8."

What about offline trucks?

When a truck loses signal (tunnels, cellular dead zones), the device buffers pings on its internal SD card. On reconnect, it bulk-publishes the buffered pings as backdated messages. We process them but show a "last seen X minutes ago" indicator so ops staff understand the gap.

Does the dashboard work on mobile?

Yes — responsive layout. We see ~62% of dashboard sessions from mobile (founder's phone, ops staff). The map renders well on iPhone 11+ and on Android devices with 6 GB RAM and up.

How long does provisioning a new truck take?

Approx 4 minutes per truck on-site. Run a CLI script, scan the device's IMEI, attach the generated cert, push to Teltonika's device-config endpoint. We trained 2 mechanics at the Surat workshop to do this — they handle new fleet additions without us.

What was the hardware cost per truck?

Teltonika FMB920 device per truck (one-time). Jio M2M SIM with 1 GB/month data plan (monthly, per truck). Installation labour at the workshop (one-time, per truck). For the 200-truck fleet, hardware capex was recovered in 14 months from the Loconav saving alone.

Can the dashboard show driver behaviour (harsh braking, speeding)?

Technically yes — Teltonika devices report acceleration events. We deliberately did not surface these to the dashboard after a conversation with the drivers' union representative. The compromise: those events are logged for internal accident-investigation purposes only, accessible by the safety officer with explicit reason, and never shown in real-time to ops staff or buyers. This was a trust trade-off and we think it was the right one.

What happens during AWS outages?

ap-south-1 has had two notable outages in the last 18 months. During both, MQTT connections from devices stayed up (IoT Core's data plane is resilient), but writes to Timestream failed. We have a 30-minute in-Lambda buffer that retries — so unless the outage exceeds 30 minutes, no data is lost. For longer outages, the device buffers locally and replays on reconnect, same as the offline truck case.

A Detail That Surprised the Founder

The dashboard was built to monitor 200 trucks. The founder used it most often to monitor 1 truck — whichever one a buyer was asking about. The "search by truck number" page became the second-most-visited screen after the map. We added a quick-action sidebar that surfaces the most-recently-searched 3 trucks, because the founder's calls with buyers came in clusters. That single feature got mentioned in 4 of 7 onboarding calls when we have referenced the build to other logistics founders since.