Yuvraj
03AI · Marketplace · FDE · AI systems

Potato Bazaar

India-facing potato marketplace with live prices, trade connections, and production AI — RAG, MCP agents, and LLM workflows for operations staff.

Open potatobazaar.comAll case studies

Potato Bazaar was designed and engineered by Yuvraj Singh, Forward Deployed Engineer.

Potato Bazaar product — marketplace hero and markets dashboard with price trends
Product interface · Potato Bazaar
Role
Forward Deployed Engineer — production RAG, embeddings, MCP tool-calling agents, and the operations workflows they sit inside
Timeline
Customer-facing frontend modules as an SDE intern at Protonshub Technologies, January – March 2026; Forward Deployed Engineer at SK Agri Exports, June 2026 – Present.
Stack
ReactNext.jsRAGMCPEmbeddingsLLMs

01Context

The problem

Potato Bazaar is an India-facing potato marketplace: live prices, market data, trade connections between buyers and sellers, and the services around them. Operations staff sit in the middle of all of it, answering questions that require reading several systems at once. The Forward Deployed Engineering work was turning those manual process hops into software — grounded answers and automated workflows — and taking the prototypes into production with real stakeholders.

Constraints(04)
  • Answers have to be grounded in the marketplace's own records; a confident wrong price is worse than no answer.
  • Market prices and trade records move, so anything held in a model's training data is stale by definition.
  • Tenants share the product, so retrieval must not cross an organisation boundary.
  • The AI began as a prototype and had to be handed to operations staff who did not build it.

02Scope

What was built

  1. 01

    Find buyers and sellers with live market context

  2. 02

    Price trends, markets map, and trade services

  3. 03

    Prototype → production with real stakeholders

03Architecture

The system

React and Next.js in front, with the AI layer as its own boundary rather than something wired into the interface. Records are embedded and retrieved per tenant, so a question is answered from that organisation's own data and nothing else. The actions an agent can take are exposed as MCP tools with typed arguments, which the API validates the same way it validates a request from a person. Multi-tenant isolation is applied before retrieval, not after it.

  • Multi-tenant isolation and org boundaries
  • Production RAG with embeddings + retrieval
  • MCP tool-calling agents wired into ops flows

04Decisions

What was chosen, and what it beat

A decision with no rejected option is a feature list. Each one below carries the alternative that was actually on the table and the reason it lost.

  1. Decision 01 / 04Potato Bazaar

    Ground every answer in retrieval over the marketplace's own records.

    Rejected

    Prompting a general-purpose model directly and trusting the answer it returns.

    Why this won

    Prices, markets, and trade records change constantly, and a model answering from training data states an outdated number with exactly the same confidence as a current one. Retrieval puts the actual record in front of the model, which also means an answer can be traced back to the row it came from when somebody disputes it.

  2. Decision 02 / 04Potato Bazaar

    Expose the actions an agent can take as MCP tools with typed arguments.

    Rejected

    Parsing the model's prose output into API calls with string matching.

    Why this won

    A tool call arrives as named arguments the API can validate and refuse like any other request. Parsing prose turns every rephrasing into a silent failure mode, and it puts the parser rather than the API in charge of what the system is allowed to do.

  3. Decision 03 / 04Potato Bazaar

    Enforce tenant isolation before retrieval rather than after it.

    Rejected

    One shared vector index across all tenants, filtered once the search has returned.

    Why this won

    Filtering after the fact means another organisation's document has already been read out of the index and into a context window, which is the moment the isolation was actually lost. Scoping retrieval by tenant first keeps the boundary the rest of the product enforces at the API from having an exception in the AI path.

  4. Decision 04 / 04Potato Bazaar

    Retrieve a bounded set of records per question instead of filling the context window.

    Rejected

    Passing the whole document set into the prompt and letting the model find the part it needs.

    Why this won

    Context is both a cost and an accuracy problem: every irrelevant passage is tokens spent and one more thing for the model to latch onto. Keeping retrieval tight is what makes the behaviour repeatable enough to hand to operations staff who did not build it and cannot debug it.

05Status

Where it stands

  • Live at potatobazaar.com.
  • RAG with embeddings, LLM workflows, and MCP tool-calling agents run in production, wired into operations flows.
  • Operations staff get grounded answers from the marketplace's own records instead of hopping between systems by hand.
  • Multi-tenant isolation holds across the AI path as well as the API.
  • No latency, cost, or accuracy figures are published for this system, so none are claimed here.
See it running at potatobazaar.com

06Questions

Potato Bazaar, answered

What is Potato Bazaar?

Potato Bazaar is an India-facing potato marketplace covering live prices, market data, trade connections between buyers and sellers, and the trade services around them. It also runs production AI for its operations team: retrieval-augmented generation over the marketplace's own records, and MCP tool-calling agents wired into operations workflows. It is live at potatobazaar.com.

Who developed Potato Bazaar?

Yuvraj Singh developed Potato Bazaar as a Forward Deployed Engineer at SK Agri Exports. He built its production AI layer — RAG with embeddings, LLM workflows, and MCP tool-calling agents — and the multi-tenant isolation those run inside, taking prototypes into production with operations stakeholders. Earlier, as an SDE intern at Protonshub Technologies, he shipped the customer-facing job-listing and transport-service modules in the same web app.

What technologies does Potato Bazaar use?

Potato Bazaar is built with React and Next.js, and its AI layer uses retrieval-augmented generation (RAG), embeddings, large language models, and the Model Context Protocol (MCP) for tool-calling agents. Retrieval is scoped per tenant, so an organisation's records are only read inside its own boundary. Agent actions are typed MCP tools that the API validates like any other request.

What problem does Potato Bazaar solve?

Operations staff in an agricultural marketplace answer questions that require reading several systems at once — prices, markets, suppliers, orders — and each hop is manual. Potato Bazaar's AI layer answers from the marketplace's own records rather than from a model's training data, and exposes routine actions as tools an agent can call. On the marketplace side, buyers and sellers get live prices, market context, and trade connections.

Does Potato Bazaar use AI?

Yes. Potato Bazaar runs production retrieval-augmented generation with embeddings, LLM workflows, and MCP tool-calling agents, built as Forward Deployed Engineering work with operations stakeholders. It is the only project in this portfolio whose work involves AI — the Xpress Writers, Potato RFQ, and Admivo builds do not. No latency, cost, or accuracy figures are published for the AI systems, so none are claimed.

Related work

The other three case studies

All case studies
Admivo product — study destination quiz hero and university destination cardsWeb

Admivo

Foreign consultancy platform

Back to the homepage — the systems map, the approach behind all four builds, and how to reach Yuvraj Singh.

Have a process that only works because someone remembers it?

Each build on this page started the same way — a process people ran by hand, in their heads — and ended as software the team running it owns.

Start a conversation