# When a Logistics Dev Shop Turns Its Internal Tool Into a Product

## The tool nobody meant to build twice

It usually starts with one client and one bad workflow. A regional trucking company hires a five-person dev shop to fix how dispatchers assign loads, because the transportation management system they bought years ago doesn't talk to their ELD data or their brokers' portals. The shop builds something custom: a dispatch board, a rate calculator, maybe a driver app. It works. The client is happy and keeps paying for enhancements.

Then a second freight company, unrelated to the first, hears about it and asks if the shop can build something similar. The shop says yes, because saying yes to paying work is what a services business does. Six months later there's a third client, and the shop has three codebases that started from the same idea and have since diverged in ways nobody documented.

This is the moment, though it rarely feels like one at the time. The shop is sitting on something that looks like a product. What it actually has is three custom builds and a founder who hasn't decided which business they're running.

## Why logistics produces this pattern so often

Freight and fleet software is a good breeding ground for accidental products because the underlying workflows (dispatch, routing, load matching, compliance tracking, driver communication) are similar across thousands of small and mid-sized carriers, brokers, and 3PLs, but the incumbent software is old, expensive, and poorly integrated. A dev shop that solves one client's version of the problem is usually only a few configuration choices away from solving a hundred companies' version of it.

That's the appeal. It's also the trap. Because the workflows are similar but not identical, every new client believes their version of the problem is special. Their brokers use a different EDI format. Their drivers use a different app. Their compliance officer wants a report shaped a specific way. Each one of these requests is reasonable in isolation and is billable. Collectively, they are how a product turns back into a services business wearing a product's marketing.

## The revenue that funds its own replacement

Billable-hours revenue is what pays the team while the founder figures out whether a product exists at all. That's not a bad use of services income, and it's a well-documented one: MIT Sloan Management Review has written about [how professional services firms turn expertise into scalable products](https://sloanreview.mit.edu/article/how-to-turn-professional-services-into-products/), and the mechanics hold in software the same way they do in consulting. The firm's growth ceiling is linear: revenue tracks headcount, because the thing being sold is people's time.

The problem is that services revenue and product revenue want opposite things from the codebase. Services revenue rewards saying yes to a custom request, because that request is billable and the client is already paying. Product revenue rewards saying no, because every custom branch is a maintenance cost that never goes away. A founder running both models on the same team is asking their engineers to serve two incompatible masters without ever forcing the conflict into the open. This is close to the situation described in [the consulting retainer that quietly replaces the product roadmap](https://humanbusinessworks.hashnode.dev/consulting-retainer-replaces-product-roadmap), except here the retainer isn't quiet. It's the entire business model, dressed up as a product company because the sales deck says "platform."

## The fork is the real decision point

The technical symptom of a stalled transition is always the same: multiple codebases, or one codebase with client-specific branches that never get merged back. Each fork is a rational response to a single client's request and an irrational response to the business as a whole. Six months in, the team is spending more engineering time keeping three forks alive than they would spend building one configurable product, but nobody has done that math out loud because nobody owns the codebase's long-term health. The founder owns client relationships. The engineers own tickets. Nobody owns the architecture as a business asset.

This is where the actual choice sits, and it's narrower than "pivot to product." The founder has to decide whether the next dollar of revenue buys another custom engagement or buys engineering time spent generalizing the existing one. Those are different hires, different roadmaps, and different answers to the next sales call. A founder who has already lived through a similar fork in a different vertical described in [funding a manufacturing software product with consulting revenue](https://humanbusinessworks.hashnode.dev/manufacturing-software-consulting-revenue-product-funding) faces the identical arithmetic: the services arm can subsidize product development for a while, but only if someone is actively converting billable hours into reusable configuration rather than reusable code with a client's name on the folder.

## Why the hybrid state is so stable

Most of these shops don't fail. They also don't become SaaS companies. They settle into a hybrid that looks busy and profitable and never quite scales, because every incentive in the business points toward staying there.

Sales likes it because a services deal is easier to close than a product commitment; you can promise anything. Engineers like the variety and the direct client contact, even as it fragments their time. The founder likes the revenue, because it's real money against a real invoice, not a hypothetical annual recurring revenue number. Nobody in the room is rewarded for turning down a six-figure custom build in favor of shipping a generic feature that might sell to nobody. Bessemer Venture Partners' operating guidance for SaaS companies is blunt about this: [the metrics and incentives that define a real subscription business](https://www.ueinvestors.com/wp-content/uploads/2012/05/Bessemers_Top_10_Laws_for_Being_SaaS-y.pdf) (net retention, gross margin from support and hosting, sales efficiency) are structurally different from a services business's, and a company can't optimize for both at once without one of them quietly losing.

KPMG's framework for SaaS transformation makes a related point about internal economics: R&D, support, and finance in a subscription business are structured around one shared product, not around whichever client is loudest that quarter, and [that structural difference is what actually breaks a hybrid model](https://assets.kpmg.com/content/dam/kpmg/pdf/2016/07/transforming-saas.pdf), not a lack of ambition.

## What actually forces the shift

The transitions that work usually involve a specific, uncomfortable decision rather than a general commitment to "go product." A founder refuses a large custom contract that would have funded six months of payroll. A team ships a configuration layer instead of a client-specific fork, even though the configuration layer takes longer and the client complains. A company splits its P&L so services and product revenue are visible separately, which makes it impossible to keep pretending the product is profitable when services are covering its losses.

None of these decisions feel like strategy in the moment. They feel like turning down money. That's usually the tell that the shift is real.