Accessibility
Make the marketplace easy to use through clear flows and voice-friendly interactions.
A real-time marketplace prototyped system where a vendor and a customer who speak different languages can agree communicate, make offers, process payments and negotiate on a price. Built solo in 24 hours for the AWS AI for Bharat Republic Day hackathon, where it won bronze .
[PLACEHOLDER: avatar]
“We struggle to reach more customers and negotiate smoothly with in person buyers who speak different languages. Also, we need a simple way to showcase our products online, suggest fair prices, and negotiate confidently while protecting our minimum profit.”
Language Barriers · Digital Visibility to regular customers · Diverse Language Marketplaces
“We find it difficult to communicate with local vendors in new places who speak my non-native language and negotiate fairer prices. We need an easy way to browse products from our familiar vendors online, negotiate comfortably in our own language, and make convenient payments.”
Non-Native Speakers · Local Market Experience
[PLACEHOLDER: avatar]
In local Indian markets, a vendor and a customer often do not always share a language, and hence purchase and bargaining on a crowded market depends on tone as much as on numbers. Also, local vendors are not available in online markets.
| Failure | Why it happens | Effect |
|---|---|---|
| Language gap | Vendor and customer may speak Hindi, Tamil, Telugu, Bengali or English. Integrating a literal translation of a bargaining message can sound blunt or rude. | Deals stall or never start |
| Unclear prices | Prices are set by the vendor, change with season and demand, and the customer has no easy reference. | Low trust in the price |
| Negotiation friction | Bargaining relies on polite, indirect phrasing and repeated counter-offers. Without a shared language, it breaks down. | Lost sales, strained relationships |
The gap is not a missing marketplace. It is a missing way for two people to negotiate respectfully in different languages.
One vendor, one customer, one shared session. Each writes or speaks in their own language, and the other reads it in theirs, phrased the way a polite market conversation would be.
| Capability | What the user gets |
|---|---|
| Location-aware pricing | The vendor gets suggested market prices for their products, adjusted for location, season and demand, instead of guessing or using a static list. |
| Cultural translation | Messages are translated across five languages (English, Hindi, Tamil, Telugu, Bengali) and rewritten in polite, indirect marketplace phrasing, not word for word. |
| Negotiation agent | The agent proposes context-aware counter-offers for up to three rounds. It never goes below the vendor's floor price, which the customer cannot see. |
| Live shared session | The vendor and customer pair up with a 6-digit session code. Cart, stock and price changes appear on both screens instantly. |
| Payment | The customer pays by UPI through Razorpay (test mode) or chooses cash, which the vendor confirms manually. |
| Enabling Digital Presence | The local vendors can list their products online, reach a wider audience, and manage their digital storefront. This also enables regular buyers of a vendor to leverage online orders |
Make the marketplace easy to use through clear flows and voice-friendly interactions.
Let vendors and customers participate in the language they know best.
Help local vendors bring their storefront and products online.
Chooses a language and product categories. The AI generates products with suggested live prices. The vendor sets a selling price and a private floor price, then shares a 6-digit session code and handles negotiation, cart updates and payment from a dashboard.
Chooses a language and enters the vendor's code. Browses live inventory, adds items (stock is checked as they add), negotiates through the AI-assisted chat, and pays by UPI or cash.
A React frontend and a Node/Express backend talk over Socket.IO for live updates. The backend calls Gemini 2.5 Flash through four separate services, each with its own API key and tuned settings.
| Layer | What it does | Built with |
|---|---|---|
| Frontend | Vendor and customer interfaces, five-language UI, voice input and output | React, Tailwind CSS, i18next, Web Speech API, ResponsiveVoice |
| Real-time layer | Session pairing, live cart and inventory sync, negotiation and payment events | Node.js, Express, Socket.IO |
| AI services | Pricing, cultural translation, negotiation agent, polite-speech conversion | Gemini 2.5 Flash, one key per service (for MVP purpose) |
| Payments | UPI order creation and verification; cash confirmation by the vendor | Razorpay (test mode) |
The size of the prototype, counted from the repository.
| What | Count | Why it matters |
|---|---|---|
| Languages | 5 | English, Hindi, Tamil, Telugu and Bengali, each with voice input and output. |
| Translation keys | 1,313+ | The whole interface is localised, not only the chat messages. |
| AI services | 4 | Pricing, translation, negotiation and polite conversion, each with its own key and settings. |
| Real-time event types | 25+ | Session, cart, inventory, negotiation and payment updates between vendor and customer. |
| REST endpoints | 10+ | Supporting services for pricing, payments and health checks. |
| Components and services | 50+ | Built solo within the 24-hour limit. |
A welcoming entry point that guides customers and vendors into the right marketplace flow.
| Decision | Why it holds |
|---|---|
| Translate for tone, not just words | A literal translation of a bargaining message can offend. A separate polite-conversion step keeps the exchange respectful, which matters more in a market than word-perfect accuracy. |
| Protect the vendor's floor price | Vendors would not trust an agent that could undercut them. The floor price lives with the vendor, and the agent cannot counter below it. |
| Cap negotiation at three rounds | Keeps bargaining from looping and gives both sides a clear end point. |
| Split AI into four services | Pricing, translation, negotiation and polite conversion have different needs (temperature, length, volume). Separate AI integrations keep one busy service from using up the quota of the others. (Optimising for the MVP) |
| Pair with a 6-digit code | No accounts or sign-up. A vendor and customer standing at a stall can join in seconds. |
| Let the AI fail visibly | There is no fallback model. If the AI is unavailable, the app says so instead of producing a lower-quality result silently. This was a deliberate trade for a 24-hour build. |
This is a working prototype built in 24 hours, not a deployed product. I want the limits to be clear:
| Area | Current state |
|---|---|
| Deployment | Runs locally. Not hosted. A demo video shows the full flow. |
| Payments | Razorpay test mode only. |
| Data | Sessions and inventory are held in memory. Nothing is stored after a session ends. |
| Catalogue | Two categories (vegetables, fruits) with five products each. |
What exists today. Open the artifacts below.
Treating tone as part of the product, and keeping the vendor's floor price out of the customer's reach, made the AI something a vendor could trust to speak for them.
Whether vendors and customers actually reach a price faster and feel respected. The next step is a small test with real vendors, a native-speaker check of the translations, persistent storage, and live payments once the flow is validated.