Role
Solo Architect and Engineer, fractional CTO
Reported to
Company CEO
Duration
9+ years
Total business processed
$10M+

The client company had been paying a third-party software company for a commercially available TMS (transportation management system) to rate, quote, book, and track shipments, but they felt the system was becoming too expensive and wasn't configurable enough to meet their internal needs. They had an ambitious project in mind to build a custom TMS, but weren't sure how to start.

At that point in my career, I had already built custom software and led technical projects in other sectors, like franchising and senior care, but had no experience building freight systems. We determined the best approach was to work slowly and deliberately toward an MVP, starting with the most impactful features first, and expanding functionality organically over time. We agreed to terms, and got to work.

Learning Freight the Hard Way

Phase one was working closely with the admin and operations teams to truly understand their workflows and the underlying concepts of the freight space. The big takeaway: freight is unpredictable and changes quickly, conditions that are fundamentally at odds with what software systems are good at. That meant the real work wasn't just building features, it was figuring out which tasks were repeatable enough to automate, and where to build in the overrides and flexibility needed to handle everything that wasn't.

It was a hard way to learn the domain, but it laid the foundation for deploying useful features quickly, and it shaped every decision that came after.

The Decision Point: Build vs. Buy

It didn't take long to start creating real productivity gains for the team, and that's when we hit the most consequential decision of the project. Most TMSs rely on third-party infrastructure to actually communicate with carriers, computer to computer. The question was whether to build that infrastructure ourselves or rent it from a third party. After testing and weighing the options, the client made the call to build it in-house.

This challenge is notorious in the freight world for its scale and complexity. Rather than be discouraged, I took the approach that we didn't need the thousands of connections that the commercially available alternative offered, just the ones that were immediately relevant to the client's business. This exercise offered a useful lesson in scoping to what's necessary instead of being overwhelmed by the scope that could be.

The Infrastructure Build

The TMS needed to talk to outside carriers electronically, and each carrier had its own protocol for sending and receiving data, with each protocol covering different services like rating. Since carrier specs could change without notice, building and maintaining required a clear roadmap and a reliable way to surface issues as soon as they were discovered. That's where I built an integrated issue-reporting system, so staff could easily flag problems to be addressed at a moment's notice. The task was daunting, but the work began, and the infrastructure ultimately proved successful.

With that in place, the system now had both core functionality and the more sophisticated capability to interoperate with outside software systems. What followed was years of fine-tuning and maintenance as the system became the operational cornerstone of the business.

Outcome

The system went on to process millions of dollars in revenue per year, and years later, it's still core to how the company runs. There were plenty of technical lessons along the way, but the deeper one was about the value of learning a domain from the ground up before trying to build for it: the freight knowledge gained in phase one turned out to be just as important as the infrastructure itself.

Technical Highlights

  • Engineered an asynchronous quoting pipeline (Celery + Redis) to query multiple slow, third-party carrier APIs in parallel, working within a strict 30-second platform timeout that would otherwise cause request failures.
  • Designed a standardized internal API layer to abstract and normalize carrier integrations across inconsistent protocols (REST, SOAP, XML) into a single, consistent data model for the application.
  • Built the core platform on Python/Django with PostgreSQL as the system of record for all shipment, quote, and user data.
  • Led a live infrastructure migration, moving cloud assets (object storage, CDN, DNS) into a fully client-owned environment with no disruption to production operations.
  • Designed a lightweight, zero-cost internal issue-tracking process so operations staff could report and track system bugs without needing a dedicated tooling budget.