InterTrio

Inspiration

BotMarket was created to help robotics teams sell and buy used parts. Teams can have boxes full of motors they don't use anymore (firsthand experience with FRC Team 1241), and BotMarket allows them to sell parts like those while helping other teams out. DayBot was used to create BotMarket, and robotics items to sell on the website were also found using their Scan.

LaunchScore was created to help DayBot founders assess the websites their platform was creating, ensuring customer retention and a high quality shopping experience. Once enough sites have been scored, patterns will emerge which can assist in bringing to light features that are excellent for a store to have or flaws that need improvement.

ListingExtract was created to help automate the manual work of adding a custom listing. By uploading a PDF with products, ListingExtract will automatically fill in the info for the custom listings, effeciently gathering data from places like Discord conversations or Slack transcripts.

What it does

You paste a store URL. In about 15 seconds, LaunchScore crawls the store, runs it through a set of checks, compares each product against real comparable listings, and returns an A to D launch-readiness grade.

The grade is broken down into five categories: Trust, Content, Pricing, SEO, and Catalog. Under the grade you get specific strengths and weaknesses, and every single finding is backed by evidence. A weakness does not just say "your descriptions are thin," it cites the rule it failed and shows how comparable listings in the same niche handle it, for example that similar products typically run around a certain word count and image count. Nothing is auto-changed. You get the findings and you decide what to fix.

There is also a patterns dashboard that aggregates every store we have audited, so you can see the most common gaps across all of them, not just your own store.

How we built it

The audit runs as a pipeline. First we crawl the store: the homepage, the policy pages, and up to eight product pages, pulling out prices, images, description length, review markup, and Product JSON-LD.

Then two things happen in parallel with the crawl results. A rule engine runs objective checks (is there a return policy, is there a concrete shipping window, is the meta description a sane length, are there duplicate titles, is the discount plausible, and so on). At the same time, we embed each product and retrieve the most similar listings from our knowledge base, then derive more findings from that comparison, like where the price sits against real comps and whether the catalog is coherent enough to read as a single niche.

The knowledge base is the part we care about most. We built it offline by pulling over 120 real product listings from about a dozen established, successful stores across kitchen, fitness, home, beauty, pets, and gadgets, plus a set of conversion guideline cards. Every item is embedded once into a local vector store, and retrieval at runtime is a search over it.

Only after all the evidence exists do we bring in an LLM. We use Google's Gemini models to write the human-readable findings and the executive summary, but it is tightly constrained. It can only use a fixed list of issue codes, it can only cite evidence we actually gathered, and we validate its output against a schema.

The app is a Next.js and TypeScript project with Tailwind for the UI, Supabase for storing audits, Zod for validation, and Vitest for tests.

Challenges we ran into

Keeping the LLM honest was the biggest one. It is very easy to get a language model to write confident sounding store advice, and very hard to guarantee that advice is true for the store in front of it. Our answer was to make evidence come first and the writing come last, and to refuse any finding that is not tied to a real rule result or a real comparable listing.

Working inside a free API tier also forced good discipline. We cap the crawl at eight products, batch our embedding calls, and rate limit everything to stay under the request-per-minute ceiling. Crawling arbitrary user-submitted URLs safely was its own problem too, so we validate targets, set timeouts, and cap how much of a page we will read.

Accomplishments that we're proud of

Every finding in a report is traceable. You can follow any strength or weakness back to the exact check or the exact comparable listing that produced it, which is rare for this kind of tool.

What we learned

We learned how much of "good store" advice can actually be made objective if you are willing to compare against real winners instead of a checklist. We also got a much better feel for building with LLMs in a way you can trust, where the model is the writer and not the source of truth.

What's next for LaunchScore

We want to widen the knowledge base to more niches and more comparable listings so the price and content benchmarks get sharper. We would like to let a store re-run its audit over time and watch its grade climb as it fixes things. Longer term, the aggregate patterns data could turn into its own benchmark for what a launch-ready store looks like in each category.