• 

  VendorMender adjusts marketplace requirements by category, vendor type, & product before processing the information provided.

• 

  VendorMender processes 20 SKUs, maps fields, checks marketplace requirements, and surfaces only the products that still need attention.

Inspiration

VendorMender came from my experience interning with an aggregator that worked with local small businesses in India. I handled vendor onboarding and catalog management, and every vendor seemed to arrive differently.

Some had structured spreadsheets. Some had incomplete catalogs. Others shared product information through messages or used their own naming conventions and formats. As someone who was just starting out, constantly adapting to these variations was time-consuming and confusing.

That experience made me question why onboarding systems expect every vendor to conform to the same form before anything can move forward.

VendorMender grew from a simpler idea: let vendors start with what they already have, and make the onboarding system adapt to them.

What it does

VendorMender is a vendor onboarding intelligence layer that accepts product information in different forms, including messages, spreadsheets, catalogs, and incomplete product lists, and turns it into structured, marketplace-ready data.

Instead of asking vendors to start over in a long standardized form, VendorMender determines what information is already available, maps it to marketplace requirements, identifies what is genuinely missing, and surfaces only the next actions needed.

For structured catalogs, it can also interpret inconsistent field names and formats. But semantic mapping is only one part of the workflow.

The larger goal is to make vendor onboarding adaptive, faster, and less repetitive regardless of how the information arrives.

How I built it

I built VendorMender as a full-stack onboarding workflow using a React/Lovable frontend, a Python FastAPI backend, REST APIs, and a backend deployed on Render.

Different vendor inputs are routed into the same underlying onboarding logic. Spreadsheet and catalog uploads are parsed into structured data, while message-based submissions can be processed as vendor information without requiring a predefined spreadsheet format.

For catalog data, VendorMender combines deterministic mappings with Gemini-based semantic interpretation to understand inconsistent fields using both column names and sample values.

Once the information is structured, it is compared against marketplace-defined schemas. A deterministic validation layer then identifies missing required information and determines readiness.

The architecture separates three responsibilities:

Input flexibility — accept what the vendor already has. Interpretation — understand and structure that information. Validation — determine what is still required before publication.

Challenges I ran into

The biggest challenge was designing one workflow that could handle vendors who submit information in completely different ways.

The system needed to work whether the starting point was a clean spreadsheet, a messy catalog, an incomplete product list, or a message, without forcing every vendor back into the same rigid form.

Another challenge was determining when automation should act confidently and when it should stop and ask for confirmation. I addressed this through deterministic mappings, semantic AI, confidence thresholds, preserved data, and marketplace-defined validation rules.

I also worked through practical challenges involving file parsing, API integration, CORS, deployment, frontend state management, and maintaining information across the different stages of onboarding.

Accomplishments that I'm proud of

I am most proud that VendorMender became a working adaptive onboarding workflow rather than just a catalog-cleaning tool.

A vendor does not have to begin with perfectly structured data. The product can start with different forms of information, understand what is already available, normalize it against marketplace requirements, and identify the remaining gaps.

I also built a working catalog intelligence layer where messy vendor columns can be interpreted semantically, while deterministic rules still control whether a listing is actually ready to publish.

The result is a system that reduces unnecessary re-entry and focuses the vendor only on the information that still needs attention.

What I learned

The biggest product lesson I learned was that efficiency does not always come from building a better form.

Sometimes the better solution is removing the requirement that everyone starts from the same form in the first place.

I also learned that AI is most useful here as an interpretation layer, not as the final decision-maker. AI can help understand different ways vendors express information, while deterministic marketplace rules provide consistency and reliability.

What's next for VendorMender

The next step is making VendorMender even more flexible across input formats.

I want to expand support for PDFs, product images, richer natural-language conversations, persistent vendor profiles, and direct marketplace integrations so information can be reused instead of repeatedly requested.

Longer term, VendorMender could become a continuous onboarding layer between sellers and marketplaces, capable of understanding information from multiple sources and converting it into the structure each marketplace needs.

The goal is not to make vendors better at filling forms. It is to make the forms less necessary.

Built With

• ai-automation
• catalog-management
• data-validation
• excel-processing
• fastapi
• gemini-api
• human-in-the-loop
• json
• lovable
• marketplace-onboarding
• natural-language-processing
• pandas
• product-data
• python
• react
• render
• rest-api
• schema-mapping
• semantic-mapping
• typescript
• vendor-management
• workflow-automation