LaunchProd is a creator-economy AI platform built for a Carnegie Mellon University-founded startup — creator dashboard, manufacturer catalog with section-level RAG retrieval, agentic product-line workflow, and admin console — shipped from blank repo to live cohort in ten weeks. We were the engineering team. These are the four decisions that defined the build, the two features we cut in week one, and the one mistake we should not have made.
LaunchProd's thesis: creators are stuck on sponsorship income because there is no structured path to launching branded product lines. The platform connects creators to manufacturers, guides product development with AI, and manages the go-to-market workflow. The founders had the research, a CMU network, and no engineering team. We built it.
What made this a harder build than a standard MVP?
Three things: three user types (creator, manufacturer, admin), a retrieval layer that had to return correct answers over live private data, and an evaluation problem the founders had not yet scoped.
Most AI MVPs we are asked to build are closer to wrappers — a prompt, an API call, a formatted output. LaunchProd needed answers grounded in specific manufacturer data that changes weekly. That is a RAG build, not a wrapper. The difference is six to ten weeks of engineering, not two days.
Why RAG over fine-tuning?
The founder's first instinct was fine-tuning. We declined.
Fine-tuning a model on catalog data that updates weekly means retraining on a cadence the build cannot support. The model's knowledge would be stale before the first cohort signed in. RAG keeps the answers current without retraining — the retrieval layer always reads from the live catalog.
We built section-level chunking over the manufacturer catalog with pgvector, a cosine-similarity retrieval layer, and a refuse-to-answer threshold. That last piece — the refusal — was the most important product decision we made in the first month. When retrieval quality falls below the threshold, the system returns nothing rather than a confidently wrong answer. Users trust a system that says it does not know more than one that guesses.
The full technical implementation is in the LaunchProd RAG architecture note.
Which features did we cut in week one?
Two features that were real product needs — at the wrong time.
Social creator profiles. Creators would have public profiles visible to manufacturers browsing the catalog. Valid idea. On launch day with a seeded catalog and no organic browsing, a public profile layer adds development time without user value. We built the data model; the UI ships when manufacturers are actually searching for creators.
In-platform direct messaging. The workflow was: creator discovers manufacturer, initiates contact, negotiates terms — all inside the platform. Four weeks of engineering for a feature that requires active users on both sides. A mailto link delivered the same function on launch day. We replaced it with a one-day integration and deferred the system.
The first six weeks of manufacturer relationships developed over email anyway. Neither cut was wrong.
What shipped on day one?
Creator dashboard with product discovery and AI-assisted ideation. Manufacturer catalog with section-level retrieval and refuse-to-answer. Admin console for catalog curation and user management. Agentic product-line workflow with status tracking.
Five creators, eight manufacturers. A narrow first cohort by design — a small group generates structured feedback that a broad launch obscures.
What would we do differently?
One thing, and it cost us five weeks.
The evaluation harness came in month three. Before that, we evaluated RAG output by manual review — looking at samples of retrievals and judging quality by eye. That is not an evaluation harness. That is vibes.
Without a scoring harness, we could not tell whether changes to the chunking strategy or retrieval threshold were improving or degrading output quality. We made three parameter adjustments in weeks three through five with no reliable signal on any of them until week eight, when the harness was in place and we ran the adjustments backward.
Build the evaluation harness in week one. It costs two to three engineering days. It pays for itself the first time you change a retrieval parameter and need to know whether the change was worth it. The right question before adding AI to a product is whether you have a way to evaluate the output — because without one, you cannot improve it.
Every AI build we take now scopes the evaluation harness in the discovery document.
What does this build confirm?
- RAG over fine-tuning when the data changes. If the ground truth updates on any schedule, fine-tuning falls behind the facts. RAG keeps the answers current.
- Refuse-to-answer is a trust feature. A graceful refusal increases user confidence in the answers that come back. Build it at launch.
- Evaluation before tuning. A model that cannot be evaluated cannot be improved. Two to three days on a scoring harness pays back in every parameter change that follows.
- Narrow first cohort. Five creators and eight manufacturers generated more actionable feedback in six weeks than a broad launch would have. Signal quality decreases as cohort size increases, until you have enough data for the noise to cancel.
The LaunchProd build follows the same scope discipline we applied to ONETAPP — cut in week one, build only what proves the hypothesis.
Written 2026-07-16 by Naman Barkiya.