How Vahak Onboarded 800K Trucks Without Killing Match Quality

For: A COO or CPO at a regional freight or transport startup who has a working marketplace with early traction but whose match quality degrades visibly as supply scales — new carriers join but load acceptance rates drop, and they cannot tell whether the problem is the ranking model, thin demand on certain lanes, or a data pipeline that was never designed for the supply volume they now have

Vahak onboarded over 800,000 trucks onto its marketplace without the match quality collapse most freight platforms see at that scale, and the single decision that made it work was refusing to let new carrier data flow into the same ranking model that served verified, high-activity carriers. The cold-start problem in a two-sided transport network is asymmetric — loads are easier to onboard than trucks — and treating it as symmetric is what silently poisons match rates long before any dashboard catches it. This is a walkthrough of how the team got there, what broke first, and what generalizes.

If you run a regional freight marketplace and your acceptance rates are sliding while your supply graph looks healthier than ever, the diagnosis is probably not your model. It's your pipeline assuming all supply is equal.

The starting state: traction, but the wrong kind of growth

Vahak began as a digital freight marketplace connecting truck owners, fleet operators, transporters, and load providers across India. Early traction was strong — verified carriers, repeat shippers, lanes with thick liquidity around major industrial corridors. The matching logic was straightforward: rank trucks for a posted load based on proximity, vehicle type fit, historical acceptance rate, and lane familiarity.

That worked because the early supply pool was self-selected. Carriers who joined in year one were operators willing to adopt a digital workflow. They responded to load notifications. They completed trips. They generated the kind of behavioral signal a ranking model needs.

Then growth happened. Supply scaled into the hundreds of thousands, eventually crossing 800K trucks. And the match rate — the percentage of posted loads that found a willing carrier within the target window — started drifting down. Not catastrophically. Just enough that the ops team noticed shippers complaining about specific lanes, and enough that the carrier acquisition team kept hitting targets while the marketplace metrics quietly worsened.

What the team tried first (and why it didn't work)

The first instinct, which is the right instinct, was to assume the ranking model needed retraining. More data, fresher data, broader feature set. The team:

• Retrained on the last 90 days of acceptance and completion data
• Added features around carrier responsiveness and dwell time at pickup
• Expanded the candidate pool per load to surface more carrier options
• Tuned the notification logic to push loads to a wider radius

Aggregate match rate ticked up briefly. Then it slid again. Worse, the team started seeing a second-order problem: shipper-side complaints concentrated on specific lanes where, on paper, there was now more supply than before. New trucks were getting surfaced. They just weren't accepting. Or they were accepting and then ghosting at pickup. Or they were accepting loads that didn't match their actual operating pattern.

The retraining had pulled new-carrier behavior into the model's understanding of what "a good match" looks like — and new-carrier behavior is statistically noisier, lower-intent, and structurally different from the verified base. The model was learning from a population it shouldn't have been generalizing from.

The asymmetric cold start nobody talks about

Here's the insight that unlocked the rebuild. In most two-sided marketplace cold start problem discussions, people talk about it as if both sides have the same shape of unknown. They don't, especially in freight.

On the demand side, a posted load is a discrete, well-specified object. Origin, destination, weight, vehicle type required, pickup window, rate. You can rank carriers against it the moment it's posted. The cold-start cost of a new load is near zero because the load itself contains most of the signal you need.

On the supply side, a new truck is an entity with a stated capacity and a claimed operating region — and almost nothing else. Will this carrier actually accept loads in their stated zone? Will they show up at pickup? Will they complete? Will they damage cargo? Will they accept a return load? You don't know. The historical signal is zero.

If you feed both populations — verified carriers with hundreds of completed trips and new carriers with none — into the same ranking pathway, two things happen. First, the new carriers get under-ranked because they have no behavioral evidence, so they never get the loads they need to generate behavioral evidence. Second, when you try to fix that by boosting new carriers or down-weighting historical features, you start surfacing unproven supply to shippers who are paying for reliability. Both failure modes compress match quality. Both look like the model is broken when the model is fine — the input distribution is the problem.

The architectural call

The fix was to stop pretending it was one ranking problem. The team split supply into tiers and routed them through separate pathways with different objectives.

Tier 1: Verified, high-activity carriers

The original ranking model, largely unchanged. Features dominated by historical acceptance rate, completion rate, lane familiarity, on-time pickup, shipper ratings. Objective: maximize acceptance probability and minimize completion risk. This served the bulk of premium load matches.

Tier 2: Onboarded but unproven carriers

A separate pathway with a different objective entirely. The goal here wasn't "surface the best carrier for this load." It was "surface loads that will efficiently generate behavioral signal for this carrier." Smaller, lower-stakes loads. Lanes where the carrier's stated operating zone overlapped tightly with the load origin. Shippers who had opted into a slightly higher tolerance for first-time carriers in exchange for better rates. The model here optimized for signal generation and trip completion, not for shipper-side acceptance maximization.

Tier 3: Cold supply

Carriers who'd registered but had no completed trips. These got a probabilistic exposure pathway — they appeared in candidate pools for loads that matched their declared profile, but only after Tier 1 and Tier 2 had been exhausted or declined. Think of it as a controlled exploration budget. Not enough to compromise shipper experience. Enough to give new carriers a real shot at their first trip.

The other piece, less glamorous but equally important, was the data pipeline. The original ingestion was designed for a single ranking model and a single feature store. Splitting supply meant the pipeline had to maintain separate feature distributions per tier, separate training datasets, and separate evaluation windows. Carrier tier transitions — when a Tier 3 carrier completes their first three trips and graduates — had to be event-driven, not batch-processed, or the system would keep treating them as cold long after they'd earned trust.

What it actually moved

The headline outcome: Vahak scaled past 800K trucks across the platform without the match-rate collapse the team had been seeing in the months before the rebuild. Specific numbers belong to Vahak, but the directional results that matter for anyone reading this:

• Match quality on premium loads stabilized because Tier 1 ranking stopped getting polluted by new-carrier behavior
• Carrier activation rate — the percentage of newly registered trucks that completed at least one trip within their first 30 days — went up materially, because Tier 2 was actually designed to get them to that first trip
• Shipper complaints concentrated on specific lanes dropped, because the team could now diagnose whether a lane problem was a coverage gap or a matching gap (different fixes)
• The supply growth team could keep onboarding aggressively without the product team flinching every time the carrier count jumped

The thing that's worth emphasizing: the team didn't ship a smarter algorithm. They shipped a smarter routing of which algorithm runs on which population. Most of the modeling code already existed.

What this approach is bad at

Being honest about tradeoffs. The tiered pathway approach has real costs.

It's harder to debug. When a shipper complains about a bad match, the first question is now "which tier surfaced this carrier?" before anyone can look at features. The ops team needs tooling that the original single-model setup didn't require.

Tier transitions are the new bug surface. A carrier who should have graduated to Tier 2 but didn't, because of a pipeline lag, looks like a carrier the system is unfairly suppressing. We had to build alerting around graduation latency.

It assumes you have enough demand depth. The Tier 2 pathway only works if there are loads available that fit the "low-stakes, signal-generating" profile. On thin lanes — corridors where load volume is sparse — there's no Tier 2 inventory to give new carriers, and the cold-start problem doesn't actually get solved. It just gets isolated. Knowing where you have a coverage gap versus a matching gap is a feature of this design, not a bug, but it forces honesty about lanes where you simply don't have enough demand.

It requires committed shipper buy-in for Tier 2. Some shippers will not take first-time carriers no matter the rate discount. That's fine, but it shrinks the Tier 2 demand pool and the team has to manage that explicitly.

Lessons that generalize

If you're operating a regional freight or transport marketplace and seeing the same pattern — supply growth that doesn't translate to match-rate growth — here's what carries over.

Diagnose the asymmetry before touching the model

Run this check: pull your last 60 days of unmatched or rejected loads and break them down by the tenure of the top-ranked carriers the model surfaced. If your declining match rate correlates with newer carriers dominating the candidate pool, you have a cold start supply matching algorithm problem, not a ranking problem. If it correlates with specific origin-destination pairs regardless of carrier tenure, you have a lane coverage problem and no model fix will help.

Separate the objective, not just the features

The temptation is to add a "carrier_is_new" feature to the existing model and call it done. Don't. The objective function for verified carriers (maximize acceptance and completion) is fundamentally different from the objective for unproven carriers (efficiently generate behavioral signal). Different objectives need different models, even if they share infrastructure.

Make tier transitions event-driven

Batch graduations from one tier to the next will create a long tail of carriers stuck in the wrong tier. Every transition — first trip completed, fifth trip completed, first dispute resolved — should fire an event that re-evaluates tier assignment in near real time.

Build coverage-gap detection as a first-class metric

The architecture surfaces lanes where Tier 2 inventory is too thin to onboard new carriers. That's actionable intelligence for the supply team ("stop signing carriers on this corridor until we fix demand") and the BD team ("we need shipper accounts that ship from X to Y"). Most platforms only discover this when the carrier churn data comes in three months late.

Don't conflate AI route matching logistics with carrier ranking

Route optimization (how the truck physically gets from A to B given traffic, fuel stops, regulations) is a different problem from carrier ranking (which truck gets shown this load). Teams routinely mix these because they sound related. They're not. Solving one doesn't solve the other, and using the same model for both is how you end up with a system that's mediocre at both.

How CodeNicely can help

The Vahak engagement is the relevant reference here because the work was specifically about transport marketplace platform build at the point where supply scale starts breaking matching assumptions that worked at smaller volumes. If your situation is similar — working marketplace, real traction, match rate slipping as supply grows, and unclear whether the root cause is model, coverage, or pipeline — the engineering pattern transfers.

What we tend to do in this kind of engagement: diagnostic on whether you have a matching problem or a coverage problem (different fixes, often confused), an audit of the data pipeline to see whether it can support tiered supply at all, and then the rebuild of the ranking pathways with the kind of event-driven tier transitions and coverage-gap telemetry that don't usually exist in v1 marketplaces. You keep full IP, no vendor lock-in.

If your problem looks more like "we need to build the marketplace in the first place," that's a different conversation — see our AI studio and offerings pages for how that engagement is structured. For a personalized assessment of your specific marketplace's matching behavior, talk to us directly.

The thing to remember

How to scale freight marketplace AI is not, mostly, an algorithms problem. It's a problem of refusing to treat all your supply as belonging to the same statistical population. The 800K-truck milestone at Vahak was unlocked by a fairly boring architectural decision: route unproven carriers through a different pathway with a different objective until they've earned their way into the main one. Most of the engineering wins in two-sided marketplaces look like this. They're not new models. They're better questions about which model should be running on which data.

Frequently Asked Questions

What is the cold start problem in a two-sided freight marketplace?

It's the challenge of matching when one or both sides of the marketplace have no behavioral history. In freight specifically, it's asymmetric: loads have rich self-contained signal the moment they're posted, but new trucks have almost no signal beyond a stated capacity and operating region. Treating both sides with the same matching logic is what causes match quality to degrade as supply scales.

How do I know if my match rate problem is the model or a lane coverage gap?

Segment your unmatched loads by origin-destination pair and by the tenure of carriers in the candidate pool. If unmatched loads concentrate on specific lanes regardless of how many carriers you have, it's coverage — no model fix will help. If they spread across lanes but correlate with newer carriers being surfaced, it's the model treating unproven supply as comparable to verified supply.

Why not just add a feature for carrier tenure to the existing ranking model?

Because the objective is different, not just the input distribution. Ranking verified carriers is about maximizing acceptance and completion probability. Ranking new carriers is about efficiently generating behavioral signal so the system can learn whether they're trustworthy. One model can't optimize both objectives cleanly without compromising the dominant use case.

How long does this kind of rebuild take and what does it cost?

Both depend heavily on the state of your existing data pipeline, the shape of your supply growth, and how much shipper-side opt-in flexibility you have. Contact CodeNicely for a personalized assessment based on your platform's current architecture and metrics.

Does this apply to marketplaces outside freight?

The asymmetric cold-start pattern applies anywhere one side of the market is structurally easier to verify than the other — gig labor, home services, professional networks. The specifics of tier definitions and graduation events change, but the core idea (separate ranking pathways for unproven supply with a different objective function) generalizes well.