02B2B · Enterprise procurement platform

Potato RFQ

B2B RFQ system for sourcing potatoes at scale — post requirements, collect competitive quotes, and move from supplier discovery to orders.

Open RFQ product All case studies

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

Potato RFQ product — landing page with requirement form and buyer dashboard analytics — Product interface · Potato RFQ

Role: Forward Deployed Engineer — mapped RFQ, delivery, and supplier operations into a multi-tenant product with operations stakeholders
Timeline: Part of the Forward Deployed Engineer engagement at SK Agri Exports, June 2026 – Present.
Stack: ReactNext.jsNode.jsMulti-tenant workflows

01Context

The problem

Potato RFQ is a B2B procurement platform for sourcing potatoes at scale. A buyer posts a requirement, suppliers quote against it, and the accepted quote becomes an order — supplier discovery through to delivery. The build started as operations mapping rather than a feature list: what procurement staff actually do between a requirement and a delivery, turned into a product while those stakeholders were in the room, and taken from a working prototype to something deployed.

Constraints(04)

Buyers and suppliers use the same product and must never read each other's private records.
One requirement collects competing quotes, so quotes have to be comparable and not merely collected.
Operations staff run the lifecycle themselves; needing engineering to move a deal forward is a failure.
It had to survive the move from working prototype to deployed product with operations stakeholders watching.

02Scope

What was built

01
Requirement posting with variety, tonnage, and delivery windows
02
Quote comparison across supplier responses
03
Buyer dashboard for RFQs, quotes, and orders

03Architecture

The system

React and Next.js over a Node.js API, with tenancy the first thing a request resolves. Buyer and supplier organisations are separate boundaries rather than two roles sharing one pool of records. The RFQ itself is a state machine — requirement to quotes to order — and the buyer dashboard is a read of that state: open RFQs, the quotes standing against each one, and the orders that came out of them.

Multi-tenant buyer/supplier boundaries
RFQ → quote → order state machine
Operational dashboards over procurement data

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.

Decision 01 / 03Potato RFQ
Model procurement as an explicit RFQ → quote → order state machine.
Rejected
Letting each screen set status fields on the RFQ record as the deal moved along.
Why this won
Several suppliers quote against one requirement, and the deal can only be in one place at a time. Named transitions make the buyer dashboard a read of state rather than a guess at it, and they are what lets operations move a deal forward on their own: the allowed next steps are a property of the model, not knowledge held by whoever built the screen.
Decision 02 / 03Potato RFQ
Resolve the tenant before the query, so buyer and supplier data sit on opposite sides of a boundary.
Rejected
Keeping one shared pool of records and separating buyers from suppliers with a role flag.
Why this won
A buyer must not be able to read a competitor's quote, and a supplier must not be able to read the buyer's other suppliers. A role flag is a filter somebody has to remember to apply to every new query, and the failure is silent when they forget; a tenant boundary is the default that a query cannot be written without.
Decision 03 / 03Potato RFQ
Capture requirements as structured fields — variety, tonnage, delivery window.
Rejected
A free-text requirement box that every supplier interprets in its own way.
Why this won
Quotes are only comparable if every supplier answered the same question. Structured fields make the quote table sortable across suppliers and give the resulting order a definition of what was actually agreed, instead of a paragraph the two parties can read differently once delivery is due.

05Status

Where it stands

Live at advance-rfq-saas.potatobazaar.com.
Buyers post requirements, compare quotes from suppliers, and track orders from one dashboard.
Multi-tenant buyer and supplier boundaries hold the two sides of the marketplace apart.
Operations staff run the RFQ → quote → order lifecycle without engineering involvement.

See it running at advance-rfq-saas.potatobazaar.com

06Questions

Potato RFQ, answered

What is Potato RFQ?

Potato RFQ is a B2B procurement platform for sourcing potatoes at scale. Buyers post a requirement with variety, tonnage, and a delivery window; suppliers quote against it; and the accepted quote becomes an order, all tracked from a buyer dashboard. It is live at advance-rfq-saas.potatobazaar.com.

Who developed Potato RFQ?

Yuvraj Singh developed Potato RFQ as a Forward Deployed Engineer at SK Agri Exports, the company behind Potato Bazaar. He mapped the RFQ, delivery, and supplier operations that procurement staff actually run, then took the system from a working prototype to a deployed multi-tenant product alongside those operations stakeholders.

What technologies does Potato RFQ use?

Potato RFQ is built with React and Next.js on a Node.js backend, structured around multi-tenant buyer and supplier workflows and an RFQ → quote → order state machine. No AI systems are claimed for Potato RFQ: of the four products in this portfolio, only the Potato Bazaar work involves RAG, agents, or LLMs.

What problem does Potato RFQ solve?

Procurement at scale means one requirement, several competing suppliers, and a deal that has to stay legible to everyone while it moves. Potato RFQ makes requirements structured so quotes are comparable, keeps buyer and supplier records on separate sides of a tenant boundary, and models the progression from requirement to quote to order as explicit states. Operations staff can run that lifecycle without engineering help.

Related work