How Vahak Onboarded 800K Trucks Without Breaking the Marketplace

For: A CTO or Head of Product at a Series A–B marketplace startup in an unorganized, relationship-driven industry — trucking, construction supply, agri-commodities — who has a working MVP but is hitting a cold-start and liquidity problem: supply signs up but never transacts, demand posts loads but gets no reliable match, and the ops team is manually brokering deals to keep GMV numbers alive

Vahak scaled to hundreds of thousands of trucks on the platform not because the matching algorithm got smarter, but because the team stopped modeling truck availability as a boolean. Once availability became a probabilistic window — informed by driver behavior, route preference, and backhaul economics — the match acceptance rate climbed, ops load dropped, and the marketplace stopped bleeding trust on both sides. This post walks through what broke, what the team tried first, and the architectural call that actually unlocked liquidity.

If you are running a Series A/B marketplace in trucking, construction supply, agri-commodities, or any industry where offline brokers still carry the real logic in their heads — the pattern below will feel uncomfortably familiar.

The starting problem: a marketplace that looked healthy on the dashboard

Vahak's original thesis was simple. India's trucking market is enormous, unorganized, and run on WhatsApp and phone calls between transporters, load owners, and brokers. Digitize the discovery layer, standardize the load-post format, and matching should follow.

The MVP did what MVPs do. Truckers signed up. Load owners posted freight. The homepage lit up with live counts. Investors saw a two-sided graph going up and to the right.

Inside the building, the numbers told a different story:

• Registered trucks were growing fast, but the share that transacted in any given week was low.
• Load owners were posting freight, getting a flood of low-quality bids or no bids at all, and going back to their broker.
• The ops team was quietly running a shadow marketplace on WhatsApp — calling drivers, negotiating rates, confirming pickups — to keep GMV pointing up.

This is the shape of every cold-start problem in a relationship-driven industry. Supply signs up because the app is free and someone on YouTube said it might get them loads. Demand posts once, gets burned, and leaves. The ops team becomes a human matching engine, which is expensive and does not scale, and worse — it hides the real failure mode from the product team.

What the team tried first (and why it did not work)

The obvious diagnosis was: our matching algorithm is too dumb. So the first wave of fixes targeted the algorithm.

Attempt 1: better geospatial filters

Tighten the radius. Rank trucks by distance to pickup. Weight recent activity. This helped surface-level relevance — a load in Nagpur stopped showing to a truck last seen in Guwahati — but did not move acceptance rate meaningfully. Trucks that looked available on the map were not actually available. Drivers had committed to a return load. Or the truck was in the yard for repair. Or the owner was holding out for a better rate on a different lane.

Attempt 2: richer truck profiles

Add body type, tonnage, permit states, preferred lanes. This helped filter obvious mismatches but did not fix acceptance. A 32-foot multi-axle whose profile said "prefers Mumbai–Delhi" would still reject a Mumbai–Delhi load if the rate was 8% below the day's spot market, or if it meant an empty return.

Attempt 3: notification blasting

If precision was hard, try recall. Notify more trucks per load. This spiked short-term match volume and destroyed long-term trust. Drivers started muting notifications. Load owners started getting bids from trucks that had no intention of actually running the load — they were fishing for rate information.

Each fix was a reasonable engineering response to what looked like a ranking problem. None of them worked because the problem was not ranking. The problem was that the data model was lying.

The architectural insight: availability is a distribution, not a flag

Here is the reframe that mattered. In the original schema, a truck was available: true/false, with a last-known location and a preferred lane list. That model implicitly assumes the platform knows whether a truck can take a load right now.

It does not. It cannot. What the platform actually has is signal:

• How often has this driver accepted loads in this lane in the last 30 days?
• When was the last time the GPS pinged from a delivery location?
• What is the typical turnaround between drop and next pickup for this owner?
• Does this operator historically take backhauls, or do they run one-way and deadhead?
• What rate band did they accept last time on this corridor?

Every one of those signals is probabilistic. Stitched together, they answer a much more useful question than "is this truck free?" They answer: what is the probability this specific truck accepts this specific load at this specific rate in this specific window?

That is the model an offline broker runs in their head. They do not have a live availability feed. They have relationships, memory of last week's conversations, a sense of who is likely to be near Bhiwandi on Thursday, and a read on which owners are aggressive on rate. The reason brokers beat platforms in this industry is not information — it is that their internal model is probabilistic and the platform's is binary.

Once the team accepted that, the architecture rewrote itself.

The rebuild: what actually changed

1. Availability became a scored window, not a state

Instead of storing is_available, the system started computing a per-truck, per-corridor, per-time-window availability score. The inputs: last known location and time, historical activity pattern for that driver and owner, days since last completed trip, seasonality on the corridor, and a decay function over stale signals. A truck that had run three Delhi–Ahmedabad trips in the last two weeks and pinged from Ahmedabad this morning had a high score for a Gujarat-outbound load tomorrow. A truck last seen three weeks ago in a random state got a low score, regardless of what its profile claimed.

2. Matching optimized for acceptance probability, not proximity

The freight matching algorithm stopped returning "the N closest trucks that match the filter." It started returning "the N trucks with the highest joint probability of accepting and completing this load." Proximity was one input. So were rate fit (does the posted rate sit inside this operator's historical acceptance band?), lane familiarity, and backhaul economics — if we send this truck from Chennai to Kolkata, what is the historical probability they find a return load, and does that show up in their willingness to quote?

3. Backhaul as a first-class object

The empty-mile problem is what everyone in trucking talks about. The temptation is to solve it with a routing algorithm — some kind of AI route optimization for logistics that pairs outbound and return loads. That was tried. It worked in slides. It did not work in the field because the return load rarely exists at the exact moment the outbound is being quoted.

What worked better: modeling backhaul probability per corridor and letting it flow into the rate expectation. If a lane historically has a 70% chance of a return load within 48 hours, the outbound rate the truck will accept is materially different from a lane with a 15% return probability. Once that showed up in the pricing surface, load owners posting on thin corridors could see why their rate was not clearing, and truckers stopped rejecting loads that looked underpriced on the surface but were actually fine given the return economics.

4. Trust signals that reflected behavior, not vanity

Ratings in an unorganized industry are noisy. Drivers do not rate load owners. Load owners rate drivers only when something goes wrong. The team replaced the star system as a primary trust input with observed behavior: on-time pickup rate, cancellation rate after acceptance, dispute frequency, payment reliability. These are hard signals that show up in the data whether the user rates or not. They fed directly into both ranking and the availability score — a driver with a 20% post-acceptance cancellation rate was not "available" in any meaningful sense, and the model learned to discount their signal.

5. The ops team became a labeling function, not a matching engine

This was the underrated change. The ops team was not fired or shrunk overnight. Their role shifted. Every manual match they closed got captured with structured metadata: why did the algorithmic top-5 not work here? What did the trucker actually want on this lane? What did the load owner concede on? That data became training signal. The shadow marketplace stopped being an embarrassment and became the labeling pipeline. Over quarters, the algorithm caught up to the ops team on more and more corridors, and ops attention moved to the edges where it was still needed — new geographies, new commodity types, dispute resolution.

What moved

We are not going to publish precise internal metrics here, but the direction of travel is what matters for anyone building something similar:

• Match acceptance rate climbed as the algorithm stopped surfacing trucks that looked available but were not.
• Repeat load-owner behavior improved — the honest metric of a marketplace, because it means the person came back voluntarily.
• Ops manual-match load fell as a share of total GMV, even as absolute GMV grew, which is the number that tells you the platform is actually working.
• Supply-side engagement — trucks that were merely registered started transacting — improved once the notifications they received were credible enough that opening the app was worth their time.

The platform now serves a large truck and transporter base across India. The interesting part is not the top-line count; it is that the count is a byproduct of getting the matching data model right, not the goal itself.

What generalizes to your marketplace

If you are running a marketplace in an unorganized, relationship-driven segment, most of this applies directly.

Your supply is probably lying to your database

Any binary state your suppliers self-report — available, in-stock, open-for-work — is probably wrong most of the time. It is not that they are dishonest; it is that maintaining a live state is work they will not do for free. Replace self-reported state with inferred state, computed from behavior. This is true for construction material suppliers, agri-commodity aggregators, small manufacturers, and services marketplaces.

Your ops team is your best training data source

Do not treat the shadow marketplace as technical debt to be eliminated. Instrument it. Every manual close is a labeled example of what your algorithm missed. Build the pipeline that captures the reasoning, not just the outcome. This is how you compress the gap between algorithmic and human matching without firing the humans first.

Backhaul economics are hiding in every asset-heavy marketplace

If your supply side owns an asset that has to reposition — trucks, cranes, containers, technicians with vans — the economics of the return leg are shaping their acceptance decisions on the outbound leg, whether you model it or not. Making that visible in the pricing surface aligns supply and demand better than any ranking tweak.

Trust is a behavioral signal, not a rating

Star ratings in low-density, transactional marketplaces are close to useless. Behavior is not. On-time rate, cancellation rate, dispute rate, payment reliability — these are collected passively and are harder to game. Weight them accordingly.

The insight worth repeating

The 30% empty-mile problem in trucking is a supply-liquidity problem disguised as a routing problem. Every marketplace has an equivalent — a headline inefficiency the industry blames on "bad matching" that is actually a data-model problem in disguise. Find yours before you optimize the algorithm.

What this approach is bad at

To be honest about tradeoffs:

• Cold start on new corridors is worse, not better. A probabilistic model needs history. In a new geography with no behavioral data, the ops team has to carry it, and the algorithm is dead weight until enough labeled events accumulate.
• It is harder to explain to the user. "You did not get this load because your acceptance probability on this corridor at this rate was 22%" is not a message you can show a driver. Debugging a bad match takes longer.
• The model can encode bias. Drivers who did not get shown loads in the past do not generate acceptance data, and the model will keep not showing them loads. This has to be counteracted with deliberate exploration budgets — occasionally surfacing lower-scored trucks to keep the data distribution honest.
• It requires real data engineering discipline. Feature freshness, backfills, monitoring for drift — all the boring infrastructure that a rules-based matcher does not need.

How CodeNicely can help

The Vahak build is one of our longer-running logistics engagements, and the pattern above — starting from a working MVP with a liquidity problem, rebuilding the data model, and reshaping the ops team into a labeling function — is the shape of most useful work in this segment. If you are at Series A/B in a relationship-driven marketplace and your ops team is stitching deals to keep GMV alive, the Vahak case study is the closest reference point in our portfolio. What matched there and is likely to match your situation: an offline industry with strong incumbent brokers, self-reported supply data that could not be trusted, and a matching problem that looked algorithmic but was actually a schema problem.

Where we tend to add value: sitting with your ops team for a week to reconstruct the mental model brokers are using, then translating that into a data model your engineering team can maintain. We work on applied AI in production systems rather than pilots, and you keep full IP on what we build. If your marketplace is in a different vertical — construction supply, agri, B2B services — the underlying playbook usually transfers; the domain-specific signals do not, and that is the part worth spending time on together.

Frequently Asked Questions

Why do most logistics marketplaces fail at matching even with good algorithms?

Because the data model treats supply availability as a binary flag when it is actually a probability distribution. The algorithm ends up optimizing for matches it can technically make rather than matches that will be accepted and completed. Fixing the ranking model without fixing the availability model produces marginal gains at best.

How do you build a freight matching algorithm when suppliers do not update their status?

Stop asking them to. Infer availability from behavioral signals: GPS pings, historical trip cadence, lane preference, time since last completed delivery, rate acceptance patterns. Passive signals are more reliable than active self-reporting in any industry where the supply side has no strong incentive to maintain status.

Should we shut down our manual ops team once the algorithm improves?

No, but you should change what they do. Every manual match is a labeled example the algorithm can learn from. Instrument the ops workflow so their reasoning is captured, not just the outcome. Over time, ops attention moves to edges — new geographies, new commodity types, disputes — while the algorithm handles the core corridors.

How do we handle the cold-start problem on new routes or new supply?

Accept that the algorithm will be weak until behavioral data accumulates, and staff ops accordingly on new corridors. Run deliberate exploration — surface some lower-confidence matches on purpose — so you build the labeled data set the model needs. Trying to launch a new corridor purely algorithmically usually fails.

How long and how much does it take to rebuild a marketplace matching system?

This depends heavily on the state of your existing data pipeline, the number of corridors or verticals in scope, and whether you have historical behavioral data to start from. Contact CodeNicely for a personalized assessment based on your current architecture and marketplace stage.