How Vahak Onboarded 800K Trucks Without Breaking the Marketplace

For: A COO or CTO at a mid-size freight brokerage or logistics aggregator who has just secured funding to digitize their broker network and is trying to understand what breaks at scale before they build it — not after

The bottleneck in scaling a freight marketplace past 100,000 carriers is not the matching algorithm. It is the data quality of the supply side. If you do not build normalization and trust-scoring into onboarding before you build matching, your algorithm will optimize confidently against garbage — and you will not know it until shipper complaints spike. This is the story of how Vahak, one of India's largest trucking marketplaces, got to roughly 800K registered trucks and 10L+ (1M+) transporters on the platform, and the architectural calls that actually mattered.

If you are a COO or CTO who just closed a round to digitize a broker network, read this before you write the PRD. Most of the mistakes are cheap to avoid on day one and expensive to fix at 50,000 carriers.

The original problem: a two-sided market where one side barely uses smartphones

Vahak's premise is straightforward. Shippers post loads. Truck owners and fleet operators bid or accept. The platform takes a cut or subscription. In principle, this is the same shape as any two-sided marketplace — Uber for freight, if you must.

The reality on the supply side is not that clean. A material share of Indian truck owners operate one to five vehicles. Many are first-generation smartphone users. Literacy varies. Language varies — Hindi, Punjabi, Tamil, Telugu, Kannada, Marathi, Gujarati. Route knowledge is tribal, passed down through brokers (dalals) who take a spread and hold the relationship. The digital-native assumption that underpins most marketplace design — clean profiles, verified identities, structured inputs, GPS-enabled everything — collapses in this market.

The original brief to the engineering team was, roughly: build a fast, mobile-first marketplace with load posting, bidding, tracking, and payment. What the team learned in the first year is that the marketplace was the easy part. The hard part was making sure the supply side that showed up was actually usable.

What "usable supply" actually means

A registered truck is not the same as a bookable truck. For a truck to be genuinely useful to a shipper searching for capacity on a specific lane, the platform needs to know, at minimum:

• The truck exists and is roadworthy (RC verification against Vahan)
• The owner controls the truck (not a lead-gen scraper who signed it up)
• The truck actually operates on the lanes the profile claims
• The capacity, body type, and axle configuration are correct
• The owner is reachable and will actually respond to load offers
• Historical behavior — does this operator ghost, cancel, or complete?

None of that comes for free at signup. And every one of those attributes degrades in different ways at scale.

What the team tried first — and where it broke

The first version of onboarding was the version every marketplace ships: phone OTP, minimal profile fields, self-declared truck details, and a "we'll verify later" posture. Growth was the priority. Get supply on the platform. Sort it out downstream.

This works until it doesn't. At the low tens of thousands of registered trucks, three failure modes surfaced simultaneously:

1. Duplicate and fake listings

The same truck registration number appeared under multiple accounts. Brokers were signing up trucks they didn't own to intercept load offers and resell them. Some accounts had ten, twenty, fifty trucks claimed with no supporting documents. From a marketplace-liquidity graph, this looked like healthy supply growth. From a shipper's perspective, it looked like calling five numbers to book one truck.

2. Lane data was almost entirely wrong

Self-declared lanes ("I run Delhi–Mumbai") turned out to be aspirational rather than descriptive. Operators picked popular lanes to show up in more searches, not the lanes they actually ran. Matching-layer engineers noticed early that recommended trucks for a Bangalore–Chennai load were routinely rejecting the load because they were nowhere near Bangalore. The algorithm was optimizing against a fiction.

3. Response rate collapsed as the funnel widened

Once a load offer went to a broader pool of "matched" trucks, response rates fell. Shippers experienced this as the platform being slow or unreliable. Engineering experienced it as a matching problem. It wasn't. It was a supply-quality problem dressed up as a matching problem.

The instinct at this point — the wrong instinct — is to invest in the matching layer. Better ranking, better ML features, better ETA prediction. The team did some of that. It did not move the numbers that mattered.

The architectural call that actually unlocked scale

The decision that changed the trajectory was moving verification and trust-scoring upstream of matching, and treating the onboarding pipeline itself as the core product surface — not a form to get past.

Concretely, this meant restructuring the supply-side data model around four separable layers:

Layer 1: Identity and asset verification

RC verification against government sources (Vahan/Parivahan) became mandatory before a truck could receive load offers, not before signup. Signup stayed frictionless — a phone number and a language selection — because friction at the top of the funnel kills marketplaces in this segment. But an unverified truck was invisible to shippers. This one change killed most of the duplicate-listing problem without measurably hurting registration growth.

Layer 2: Behavioral trust score

Every account accumulated a behavioral signal set: response time to load offers, acceptance rate, cancellation rate, completion rate, shipper ratings, dispute frequency. This wasn't a single score — it was a vector, because different shippers weigh things differently. A high-value FMCG shipper cares about on-time delivery. A commodity shipper cares about price and availability. The trust vector fed the matching layer as features, so ranking naturally down-weighted flaky operators without any manual intervention.

Layer 3: Inferred lane graph

Instead of trusting self-declared lanes, the platform started inferring lanes from actual behavior — bids placed, loads accepted, GPS traces where available, historical completions. Self-declared lanes became a weak prior, not a fact. This is the piece most teams underinvest in. It requires patience: you need enough real behavior to infer from, which means running with imperfect matching for a while. But the compounding is enormous. By the time the platform crossed several hundred thousand trucks, the inferred lane graph was more accurate than anything a broker could tell you.

Layer 4: Normalization

Truck body types, capacities, and axle configurations were normalized against a canonical taxonomy. This sounds trivial. It is not. Operators enter "20 ft", "20ft", "20 feet", "twenty foot", "20'" and mean five slightly different things. Without normalization, filter-based search does not work, and neither does any downstream aggregation. The team built an entity-resolution layer that ran on both new inputs and historical data, with human review only on ambiguous cases.

The general principle: the matching layer should consume clean, trust-weighted supply — not raw supply. If your matching engineer is writing heuristics to work around bad profile data, you have built the wrong thing.

What this moved

The numbers that shifted after this restructuring:

• Registered trucks grew to roughly 800K, with transporters crossing 1M, without a corresponding collapse in per-load response quality
• Shipper-side complaints about unreachable or wrong-lane trucks dropped materially — the exact figure depends on cohort and lane, but the direction was consistent
• The matching layer became simpler, not more complex, because most of the hard work was happening upstream
• Support cost per booking decreased because fewer bookings required human intervention to unstick

What did not improve, and worth being honest about: the platform still cannot fully solve the human trust layer. A first-time shipper booking a first-time truck operator on a new lane is still a judgment call. Trust scoring reduces the surface area of that problem — it does not eliminate it. Marketplaces that promise otherwise are lying to themselves.

Lessons that generalize to any freight marketplace

If you are building a logistics marketplace platform — freight, last-mile, cross-border, or a broker aggregator — most of these will apply.

1. Signup friction and verification friction are different problems

Keep signup ruthlessly simple. Push verification to the point where verification actually matters — right before a truck becomes bookable, right before a shipper posts a paid load. Conflating these two decisions is the single most common mistake early marketplaces make.

2. Assume self-declared data is aspirational, not descriptive

Every field an operator fills in is a marketing message to the algorithm, not a factual claim. Design the data model to treat self-declared data as a prior that gets overwritten by behavior over time. Never let self-declared fields drive matching decisions on their own past the first few weeks of an account's life.

3. Trust is a vector, not a score

A single 0-to-5 rating is lossy and gameable. Break trust into observable components — responsiveness, acceptance, completion, disputes, on-time — and feed them as features to whichever layer needs them. Different shipper personas will weigh them differently, and that is fine.

4. The lane graph is the moat, not the app

Any competent team can ship a load-posting app in a few months. The thing that compounds — the thing a competitor cannot copy by hiring your ex-engineers — is the behavioral graph of who actually runs which lanes with which reliability. Invest in the pipeline that builds this graph from day one. Instrument everything. Store raw events even if you do not know what you will do with them yet.

5. AI route optimization is downstream of clean supply data

Everyone wants to talk about AI route optimization in logistics. It is a real and useful capability. But routing models trained on messy supply data will confidently produce plausible-looking routes that no truck will actually take. Get the supply layer clean, then optimize. Not the other way around.

6. Regional and language design is not a translation problem

Supporting seven languages is not seven times the string files. It is different keyboards, different number formats, different literacy assumptions, voice-first flows in some markets, script-agnostic search, and pricing conventions that vary by region. Build for this on day one or refactor painfully at 100K users.

7. Brokers are not the enemy

The temptation in every marketplace-disintermediation story is to route around the middleman. In Indian freight, the broker (dalal) holds real relationships and real trust. The platforms that scaled did not eliminate brokers — they gave brokers better tools and let market forces sort out the economics. Design for the incumbent's workflow, not against it.

Where this approach is bad

Being honest: the trust-vector, inferred-lane-graph approach is data-hungry. It works badly when the platform is small. For the first several thousand carriers, you are running on weak priors and self-declared data, and matching quality will be visibly worse than a well-run manual brokerage. There is a valley you have to cross before the graph is dense enough to be useful. If your investors expect linear liquidity growth from month one, this architecture will look like it is failing. Plan for that conversation before you raise.

It is also over-engineered for smaller, single-region, single-lane-type marketplaces. If you are building a cold-chain-only network with 500 carriers and long-term contracts, most of this is overkill. Trust-score your carriers manually. Skip the graph. Come back to this architecture when you cross the point where humans can no longer hold the network in their heads.

How CodeNicely can help

The Vahak build is the closest analog we have to what a mid-size freight aggregator faces when moving from a broker-desk operation to a platform. If you are digitizing a network of carriers, our team has worked through the specific failure modes described above — duplicate listings, self-declared lane fiction, response-rate collapse, normalization at scale — and knows which architectural decisions are cheap to make early and which ones compound painfully if deferred.

Where we tend to add the most value on freight marketplace development engagements: designing the supply-side data model and verification pipeline before matching gets built; instrumenting the behavioral event stream so the trust and lane graphs can be trained later; and integrating with government and telematics data sources (Vahan, FASTag, GPS providers) without letting any one integration become a single point of failure. Full IP ownership stays with you. No vendor lock-in on the data layer, which matters more than most founders realize until they try to switch a piece of infrastructure at year three.

If your situation is closer to modernizing an existing TMS or broker-desk operation rather than building greenfield, our digital transformation practice handles the legacy-system side — pulling structured data out of spreadsheets, WhatsApp threads, and desktop tools into something a marketplace layer can actually consume.

Frequently Asked Questions

What is the biggest mistake teams make when building a freight marketplace?

Building the matching algorithm before the supply-side data pipeline. Matching engines are interesting engineering problems, so teams gravitate to them. But if the supply data feeding the matcher is dirty — duplicate trucks, self-declared lanes, unverified capacity — the algorithm will produce confident, wrong recommendations. Fix the supply layer first.

How do you handle carriers who don't use smartphones well?

Design for voice, minimize typing, use icons and images heavily, support regional languages natively (not as translation overlays), and assume WhatsApp is a real channel — not a fallback. In some segments, letting a broker or family member operate the account on behalf of a driver is a legitimate design pattern, not a workaround. Do not force digital-native workflows on users who are not digital-native.

Do we need AI or ML from day one?

No. For the first several thousand carriers, heuristics and rules will beat models because you do not have enough behavioral data to train anything useful. What you do need from day one is the event instrumentation — every bid, acceptance, cancellation, GPS ping, dispute — stored in a way you can train on later. The ML comes when the data density is there.

How do you prevent brokers from signing up trucks they don't own?

RC verification against government sources before a truck becomes bookable, combined with behavioral checks — a broker managing many trucks will show different patterns than a fleet owner. You will not eliminate this fully; the goal is to make it uneconomical relative to using the platform honestly. And in many cases, brokers managing fleets is a legitimate use case that just needs a proper role model in the product.

How long does it take to build something like Vahak, and what does it cost?

The honest answer is that it depends heavily on scope, region, existing systems, and how much of the trust/verification stack you want in v1 versus v2. For a specific assessment tied to your funding, network size, and target lanes, contact CodeNicely and we will scope it against your actual situation rather than a template.