The challenge
An Indian logistics marketplace set out to connect freight and shipping companies that have cargo to move with companies that can carry it. It needed a freight matching platform where members could post what they needed shipped and find partners for it, without handing their contacts to everyone who browsed the site.
Freight requirements come in many shapes. A full container load needs different details from a part load. Air freight, loose road transport, container inquiries and import inquiries each carry their own fields. One generic posting form would either ask too little or bury members in questions that don't apply.
Privacy mattered just as much. Freight is a competitive trade, and a company's customer contacts are part of its value. Members needed a way to signal interest in each other's loads while keeping contact details hidden until both sides agreed to talk.
What we built
We built two web portals on Node.js and MongoDB: one for member companies and one for the marketplace's own team.
The member portal.
Company registration. Companies sign up, register their business and pick the freight services they handle.
Requirements by freight mode. Members post FCL, LCL, air, loose transport, container and import inquiries, each with the fields that mode needs.
Show interest. Members filter open requirements and register interest in the ones they can serve.
Contacts on acceptance. Contact details appear only after the poster accepts that interest.
Email digest. New requirements arrive in members' inboxes, so nobody has to keep refreshing the site.
The admin portal. The marketplace team manages companies, requirements and payments. It also maintains the master data every posting depends on: ports, countries, states and cities. Reports show activity across the marketplace.
How it works day to day
Take a freight forwarder with a part container load to move. They choose the LCL form, fill in the fields that matter for that mode, and post the requirement. Their company name is visible to other members; their phone number and email are not.
Elsewhere, a carrier that handles that route sees the requirement in its email digest. It opens the portal, filters by mode and port, and shows interest. Back with the forwarder, the interest appears for review. Once they accept it, both sides can see each other's contact details and take the conversation offline.
Meanwhile, the admin team keeps the port and location lists clean, approves companies and manages payments, so every new posting starts from correct, current data.
The result
Freight companies now post a load and receive interest from relevant partners without exposing their contacts first. The operator controls membership, payments and the port and location data that postings rely on.
The design choice at the center of the product, contacts revealed only on acceptance, gives members a reason to post openly. They can test interest in a load without giving away who they work with.
What the research says
Consent has to be a clear action. India's Digital Personal Data Protection Act, 2023 says consent must be free, specific, informed, unconditional and unambiguous, given through a clear affirmative action and limited to the data needed for its purpose (DPDP Act, section 6(1)). On the portal, a member's phone number and email stay hidden until the poster accepts an interest, so contacts are shared by a deliberate choice.
Short forms get finished. Baymard Institute's checkout research found the average checkout in 2024 had 11.3 form fields when most sites need only 8, and 17% of users have abandoned an order because the process was too complex (Baymard Institute). Giving each freight mode its own form asks only the questions that load needs.
Email is part of daily internet use. The IAMAI and Kantar Internet in India 2024 report counted 886 million active internet users, 666 million of whom use it for communication such as chat, email and calls (IAMAI and Kantar, 2024). An email digest brings new requirements to members who don't log in every day.
Where AI fits next
The portal does not include any of this yet. A model could rank new requirements for each member by the routes and modes they usually handle. It could read a free-text inquiry and fill in the posting form for the member to check, and flag duplicate or suspicious postings for the admin team.
Planning a freight matching platform?
Before you build a marketplace for freight requirements, it helps to answer four questions:
Which freight modes will you support at launch, and which fields does each one truly need?
At what point are contacts revealed, and can either side withdraw?
How will members pay: membership, per match or a subscription?
Who owns the port and location data, and how often is it reviewed?
Our web application development and custom software pages explain how we approach portals like this. Read our guide to choosing a tech stack for your web application, or browse more of our projects.
You can find similar systems under operations and logistics.
