Minds: From data to insights at the speed of thought

MindsDB started as an AI company built on a straightforward idea: connect your data, then run machine learning on top of it. That was before large language models became what they are now.

When OpenAI launched ChatGPT, the expectation shifted almost overnight. People no longer wanted to write a SQL query to get an answer out of their data. They wanted to ask in plain English. The opening was obvious: the same insights, reached through conversation instead of code.

So my manager and I started exploring how to move MindsDB off its heavy reliance on SQL and toward an experience built around chatting with your data.

Here is what made the project genuinely hard, and what set us apart from most of the field. Almost everyone building with LLMs at the time was working with unstructured data. If your product reads documents, a user can drop in their own public docs, ask a few questions, and judge the answers in minutes. The cost of trying you is close to zero.

We worked with structured data, which in practice meant a company's live production database, one of its most sensitive assets. No business is going to plug that into a product they just discovered, especially one running on a large outside AI lab. The trust gap was the real design problem, not the chat box.

I studied direct and indirect competitors to find where the structured and unstructured approaches overlapped, and where they split. The pattern held the whole way through: the rest of the field was solving for documents, and we were solving for databases. That one difference shaped almost every decision that followed. Our persona did not change through this work. It widened.

I built mid-fidelity screens and put them in front of users. The testing exposed a limit in the method itself. A Figma prototype can fake a few happy paths, but it cannot cover the range of real questions people throw at a data product, and that gap quietly distorts what you learn from a session.

So I made a call. For changes like these, and especially when testing with customers, I would build functional prototypes on our real backend instead of clickable mockups. My frontend background meant I had done versions of this before at MindsDB, but on its own it had never been quite enough. With AI in the loop, it finally was. The prototypes were real enough to trust, and so were the results.

Almost every AI product moves through the same underlying loop, so we wrote it down to keep our decisions honest. Two of these did the heavy lifting on this project: how people start, and how Mind answers. The rest of this is mostly about those.

The hardest moment in the product is the first one. A user lands, and we ask them to connect their data. Products built on documents can skip this tension. We could not.

We encourage people to connect, but we let them skip. When they skip, we ask one short question to learn why. Depending on the answer, they can book a call with us or try the product on a demo database.

Demo databases helped, but they did not solve it, and I think this is a problem every system that sits on top of databases shares. A demo database is small and clean. A real one is large and messy. A user can run a query against the demo and still have no idea whether the answer would survive contact with their own data.

There was a second problem underneath. People often did not know what to ask, or whether a given answer was correct, and reading the schema themselves took real time.

So we seeded the empty state with sample questions, each one carrying its own follow-ups. The goal was to lower the cost of the very first question and let people feel the system's range without sitting through a tutorial.

The aha moment still was not reliably repeatable in a first session without some setup. Closing that gap is the part I would pick up next.

The first version of Minds answered in text and tables. For a data product, that is a real limitation. A wall of numbers is hard to act on and harder to read. Today, almost every AI product renders charts in its answers. Back then, almost none did.

I wanted charts in the responses. By that point I had a rule, learned the hard way at MindsDB: in this era, a static prototype convinces no one. If you believe in something, build it.

So I used our backend directly to build a working prototype, validated the idea on real data, and saw it ship in a short window.

What I wanted was dashboards. What we shipped was charts inside chat responses. The difference was quality and depth of experience, and the gap traced straight back to something our own research had already shown me: people still want real control, not everything funneled through a single input. Chat is a fast way in. It is not the whole product.

That tension, fast conversational answers versus the depth a data team actually needs, is the most useful thing I learned on this project. It is still where I would push hardest if I picked it up again.

A short aside on personality, because it shaped how the product feels. Early on there was a quiet debate about how to represent an AI's actions: a brain, a magic wand, sparkles, a bot.

I did not spend long there. That debate matters when you are adding AI to an existing product. For an AI-native product like Minds, I took a different route. I explored a bear mascot drawn from our logo.

Then moved to something more geometric, a merged head and brain that fit our B2B vision better.

I also let the writing carry a little personality at the moments that matter, like when you are about to discard a new Mind:

This was a B2B product, so impact showed up in two places: whether people actually used it, and how customers talked about it.

The clearest design-attributable signal was activation. Around 70% of users asked a question, on both the demo data and after connecting their own. That first question is exactly what the onboarding was built to produce, so the number sits right on top of the connect-or-skip flow and the seeded sample questions.

On the customer side, Robot.com runs thousands of delivery robots across university campuses and generates terabytes of logistics data a day.

That maps almost exactly onto the bet we opened with: five days of dashboard-building, replaced by a question and an answer.

Sign-up growth and per-customer cost were still being instrumented when I left, so the long-term picture was not in yet. What was clear early on was strong activation and real customer pull.

Two things stuck.

The first is about the work. AI improved faster than we expected, and we held onto our old engine for talking to databases longer than we should have. A lot of what we built as careful scaffolding, the model could increasingly handle on its own, and the extra layers sometimes made the experience worse instead of better. Knowing when to stop designing around the model turned out to be its own skill.

The second is about the craft. The design process itself changed under us. When anyone can build, building is no longer the differentiator. Quality is. That is the bar I hold now.