SellerLens
A marketplace listing is a scoring problem before it is a writing problem.
- Category
- Product
- Status
- Shipped, MVP
- Role
- Solo builder
- Tech stack
- Next.js, TypeScript, Gemini API, Supabase (Postgres), Recharts
- Timeline
- ~2 weeks
- Scope
- 4 modules, 100-point scoring engine, 1000+ products benchmarked
- Read time
- 9 min
Context
Most AI tools built for e-commerce sellers work the same way: type a product into a box, get back a rewritten title and description. That solves a writing problem. It doesn't tell a seller why their listing is underperforming, whether their price is actually competitive, or what to fix first.
SellerLens was built around a different question: what would an internal marketplace optimization tool look like if a team at Meesho, Amazon, Flipkart, or Shopify built it for their sellers? That meant treating AI as a reasoning layer on top of structured marketplace intelligence, not as the product itself.
AI never invents a score. Listing quality, pricing competitiveness, and diagnostics are all computed deterministically first. Gemini's job is to explain and rewrite, not to decide.
Decisions
- We assumed
Let the LLM generate a quality or competitiveness score directly, since it can reason over the listing text.
- We found
LLM-generated scores aren't consistent, repeatable, or explainable across runs. A seller can't act on a number that might change if you ask again.
- Therefore, we changed
Built a rule-based, 100-point deterministic listing quality engine, evaluating title quality, keyword presence, category relevance, description completeness, and attribute coverage in code. Gemini explains the score after it's computed, it never produces it.
- We assumed
Live scraping of Meesho, Flipkart, or Amazon would give the most realistic competitive benchmarking.
- We found
Live scraping ran into API unavailability, legal exposure, and rate limits, none of which are solvable at MVP speed, and none of which are necessary to prove the recommendation logic works.
- Therefore, we changed
Seeded a simulated marketplace dataset of 1000+ products across categories like Women's Fashion, Men's Fashion, Beauty, Home, Kitchen, Electronics, and Footwear, giving deterministic, reproducible benchmarking instead of a live feed that could change out from under a demo.
- We assumed
Once Gemini generates an optimized title and description, apply it automatically, that's the fastest path to value.
- We found
Auto-overwriting a seller's live listing removes their ability to catch a bad rewrite before it goes live, and erodes trust the moment one recommendation is wrong.
- Therefore, we changed
Every recommendation requires explicit seller approval, an 'Accept' step, before it's persisted to the database. Nothing is auto-published. Every generation is logged to `ai_recommendations` for a full audit trail.
- We assumed
A Chrome extension for one-click optimization inside Seller Central would be the strongest differentiator to build first.
- We found
Shipping an extension before the underlying recommendation quality was proven would mean optimizing for workflow convenience on top of a system nobody had validated yet.
- Therefore, we changed
Built a standalone SaaS product first, dashboard, optimizer, pricing, diagnostics, deferring the extension to a later phase once recommendation quality itself is the proven part.
The product
SellerLens ships 4 product modules: a Dashboard summarizing listing quality and sales at a glance, an AI Listing Optimizer that rewrites titles and descriptions against a before/after score, a Pricing Intelligence tool that benchmarks a seller's price against the category, and Product Diagnostics that explains why a listing is underperforming and what to fix first.
System architecture
Under the hood, the platform runs on a normalized schema built around marketplace workflows rather than simple CRUD: users, products, marketplace_data, ai_recommendations, category_trends, and analytics_events, 6 tables in total, with every AI generation logged for auditability.
Principles
AI is a capability layered on top of the product, not the product itself. Recommendations should be evidence-backed and explainable, a seller should be able to ask why a recommendation exists, based on what, and what impact to expect, not just accept a black box. Every action stays reversible, nothing auto-publishes. And the product optimizes workflows end to end rather than isolated screens, discoverability, pricing, and diagnostics all read from the same underlying listing data.
Results
Combining deterministic scoring with a single Gemini-generated rewrite collapses what would otherwise be manual, trial-and-error title and description editing into one review-and-accept step.
Source: Rule-based scoring + one-click AI rewrite vs. manual title/description editingConstraints
As an MVP, SellerLens intentionally operates without several things a production version would need: no Meesho, Flipkart, or Amazon Seller API access, no real seller behavioral or historical conversion data, no inventory system, no image embeddings, and no real-time search trend data. These are stated constraints, not oversights, marketplace data is simulated by design so the recommendation and scoring logic could be validated independently of API access, legality, and rate limits.
Learnings
Separating the deterministic layer from the AI layer early paid off repeatedly. Because listing scores, pricing comparisons, and trend evaluation all live in business logic rather than in a prompt, every number on screen is reproducible and explainable, which matters more for a product about seller trust than for almost any other kind of AI feature.
The approval-before-publish decision came from the same place as ApplyOS's persistence lesson: reliability and control aren't polish steps you add later, they're what make a user willing to depend on the tool for something real. A seller who has one listing silently overwritten by AI won't come back to try it again.
Notes
- Marketplace benchmarking data is simulated and seeded, not scraped live, due to API unavailability, legal considerations, and rate limits at MVP stage. See Constraints.