The Hidden Cost of Over-Engineering a Demo

But as soon as we had the product ready, we realized that piloting this and beta testing it with non-technical teams like media and federations would be hard without an interface to interact with it. We also knew that asking them to connect our MCP to Claude would've been out of question since they didn't even use an AI tool yet. Additionally, marketing our core product as an "Athletics MCP server" would've been ridiculous, since the technology is still broadly unknown even among developers.

Our first instinct was to build a custom interface to solve this problem. Something polished, branded, purpose-built to showcase what the MCP could do. We started by scoping it out. We planned authentication flows, chat UI, query history, result formatting, mobile responsiveness. We had already spent two weeks, when we realized it would take at least double that time to have and MVP version of it. That would mean at least one month of work before a single person outside our team could see the product.

Then we stopped and asked an uncomfortable question:

What are we actually trying to prove right now?

Not that we would be unable to build a beautiful interface. But in the startup world, velocity is the most imporant thing (haha did you see that? Velocity ≈Velocitra). In other words, it means to get into the market and validate the product as soon as possible. In our case the MOAT is the data and the MCP server, not an AI-tool like ChatGPT or Claude. So why should we, a tiny but enthusiatic team with limited resources, try to compute with tech giants who have probably a thousand engineers refining their UIs?

The reframe

We needed to validate demand, not demonstrate engineering capability. Those are completely different goals and they require completely different solutions.

So instead of building, we configured and used what was available. Soon we discovered LibreChat, an open source chat interface that supports MCP server integration natively. Within a few days we had a working demo environment. A polished (and more importantly afamiliar) interface where anyone could query our athletics database in plain language and get accurate, structured answers back instantly.

It looked professional. It worked. And critically, it took days rather than months. (yes, actually)

What over-engineering a demo actually costs

The obvious cost is time. Weeks of frontend development, authentication infrastructure, UI polish. All that before you know if anyone wants what you're building.

But the hidden cost is worse: you optimize for the wrong feedback. A beautiful custom interface gets feedback on the interface. A thin wrapper around your actual product gets feedback on the product. Early on, you desperately need the latter and almost never need the former.

We would have spent months building something that answered questions nobody was asking yet, while the real questions, like is this data accurate, is the query experience good enough, what use cases actually matter to real clients, would've gone unanswered.

The principle underneath (what we learnt)

Every hour spent on demo infrastructure is an hour not spent on the thing that actually creates defensible value. For us that meant the MCP tooling, the alias resolution system, the competition grouping intelligence, the proprietary data pipeline. Those are hard to replicate. A custom chat UI is not.

Open source tooling exists precisely for this situation. LibreChat, Retool, Streamlit, Gradio. They're are mature and configurable solutions for almost every demo use case imaginable. Using them is not a shortcut. It is the correct engineering decision at the validation stage.

The line we kept reminding ourselves of

LibreChat is not our (core)product. It is how non-technical users access our product today, while we focus on building what actually matters and keeping the option to integrate the service into own agentic workflows open.

That distinction sounds simple. Keeping it in mind when you want to polish something is harder than it sounds.