v1.0: Shipping an MVP for a Freight Visibility Platform in Ten Weeks
A logistics technology company had a validated idea, a signed pilot customer, and a launch date that kept slipping because the founding team's prototype couldn't survive real carrier data. A ten-week rebuild shipped a production version the pilot customer could actually run on.
- ✓Production API integrated with three major carrier data feeds
- ✓Real-time shipment tracking dashboard
- ✓Automated exception alerts for delayed shipments
- ✓CI/CD pipeline with staging and production environments
- ✓Full test coverage on core tracking logic
A signed pilot customer and a launch date on the board calendar is exactly the wrong moment to discover that your prototype cannot survive contact with a real carrier’s data feed.
Background
The company had built a genuinely useful idea: a shipment visibility platform that pulled data from multiple freight carriers into one dashboard, saving logistics coordinators from checking six separate carrier portals throughout the day. The founding team, non-technical but sharp, had commissioned a demo-quality prototype to raise a seed round and land a first pilot customer. Both worked. The prototype did not survive what came next.
A prototype that worked until real data arrived
The demo prototype had been built and tested against clean, hand-selected sample shipment data, the kind that makes for a smooth investor pitch. Real carrier EDI feeds are considerably messier: inconsistent date formats, occasionally missing fields, status codes that vary between carriers for the same underlying event. The prototype’s ingestion logic assumed clean data as the normal case, and broke, repeatedly, the moment it met a real carrier feed during the pilot customer’s onboarding.
Rebuilding the ingestion layer around the messy case, not the clean one
We rebuilt the core ingestion service from the ground up around a different assumption: that inconsistent, occasionally malformed carrier data was the normal case to design for, not an edge case to patch around later. Every carrier integration got explicit handling for missing fields, format variance, and out-of-order status updates, with test coverage built specifically against real historical carrier data samples rather than the clean synthetic data the original prototype had been validated against.
Shipping to a real go-live date, not an open-ended roadmap
The ten-week timeline was set by the pilot customer’s own commitment to their board, not an arbitrary internal estimate, which meant scope discipline mattered as much as engineering quality. We scoped the rebuild specifically to what the pilot customer actually needed on day one, a real-time dashboard, exception alerts for delayed shipments, and the three carrier integrations the pilot required, deferring everything else to a clearly documented post-launch roadmap instead of letting scope quietly expand against a fixed deadline.
Results
The platform launched on the pilot customer’s original go-live date, processing real shipment data across three carrier integrations without the ingestion failures that had derailed the original prototype, and the founding team closed their Series A four months later with the pilot as a working, referenceable customer rather than a stalled trial.
// Questions
FAQ
Why couldn't the founding team's own prototype handle real carrier data?
It had been built to demonstrate the idea to investors and early prospects, using clean, hand-picked sample data, not the messy, inconsistent formats that real carrier EDI and API feeds actually produce. That's a completely reasonable choice for a fundraising prototype and a completely wrong foundation for a paying customer's production traffic, since the two have almost opposite requirements.
Why ten weeks specifically, and not faster or slower?
Ten weeks was set by the pilot customer's own go-live commitment to their board, not by an arbitrary estimate on our end, and we scoped the rebuild specifically to what needed to be production-grade for that pilot, deferring features the pilot didn't actually require. A faster timeline would have meant cutting the test coverage and error handling that made the pilot survive real carrier data in the first place.
What was different about building this version versus the original prototype?
The original prototype had no automated tests and handled carrier data with a set of assumptions that broke the first time a real shipment update arrived in an unexpected format. We rebuilt the ingestion layer to expect and handle malformed and inconsistent carrier data as the normal case, not the exception, with test coverage specifically targeting the edge cases that had broken the prototype during earlier pilot attempts.
Working on something similar?
Tell us what you're building, or trying to fix.