Permission is hereby granted, free of charge, to any person obtaining a copy<br>of this software and associated documentation files (the "Software"), to<br>deal in the Software without restriction, including without limitation the<br>rights to use, copy, modify, merge, publish, distribute, sublicense, and/or<br>sell copies of the Software, and to permit persons to whom the Software is<br>furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in<br>all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR<br>IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,<br>FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE<br>AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER<br>LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING<br>FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS<br>IN THE SOFTWARE.<br>-->Does Your Startup Need an AI Data Analyst? - Hadi Javeed's blog Skip to content
Initializing search
Does Your Startup Need an AI Data Analyst?¶<br>Most startups do not need a full data platform on day one. But at some point, the same questions start showing up every week.<br>How many active customers do we have? Which accounts are slipping? Did patient engagement improve after the last release? Why did usage drop for this client?<br>For a while, the answer is simple: ask an engineer to write SQL.<br>That works until it does not. The schema gets bigger. Metrics get weird. Customer success needs answers now. Engineers become the query interface for the company.<br>I built Byaan because we kept running into this problem at RevelAI. It is a small data agent harness that runs close to your database, learns your schema, shows its SQL, and stays read-only by default. The site is at byaan.ai.<br>Why Not Just Use a BI Tool¶<br>BI tools are useful, and I am not arguing against them. Dashboards are still the right answer for stable metrics people look at every day.<br>The problem is the long tail of questions.<br>Someone asks about one client, one cohort, one workflow, one contract, or one odd edge case. You do not want to build a dashboard for every question. You also do not want every non-technical teammate waiting on an engineer for a one-off query.<br>This is where a data agent starts to make sense. Not as a replacement for BI, but as a better interface for questions that are too specific for a dashboard.<br>Why Text-to-SQL Still Fails¶<br>The SQL is not the only hard part.<br>A model can generate decent SQL when the schema is small and the table names are obvious. Real databases are messier. Tables have history. Columns are named after old product decisions. Metrics have company-specific meanings. The right join is often not obvious from the schema alone.<br>At RevelAI, an "active customer" is not just a row in a customers table. Some clients are pilots. Some are churned but still have data. Some should be excluded from internal metrics for billing or contract reasons. That context usually lives in code, Slack, docs, and people's heads.<br>Raw text-to-SQL does not know that. It sees tables and guesses.<br>Why Not Julius, Hex, or Purpose-Built Tools¶<br>There are good products in this space. Jason Cui at a16z had a good post on X mapping the data agent landscape.<br>For us, many of those tools felt too heavy for a 20-50 person company. They also introduced more cloud surface area than I wanted. I did not want to hand a third party broad access to our production database if I could avoid it.<br>The other issue was context. A warehouse-native or SaaS data tool may understand your warehouse. It usually does not understand your application code, your internal naming conventions, or the Slack thread where the team decided how a metric should work.<br>The model was not always the bottleneck. The harness around the model was.<br>Why Not Just Claude Code¶<br>The obvious next step is to skip the product layer and point Claude Code at the database.<br>Two problems with that.<br>First, security. There should be a hard execution layer that prevents an agent from mutating the database. Relying on a prompt to stop DROP TABLE, DELETE, or a stray UPDATE is not enough. We have all seen stories about AI coding tools making destructive production changes.<br>Second, transparency. Even when the SQL runs, you still need to inspect it. You need to see the generated query, the result, the chart, and the assumptions before the answer ends up in a board deck or a customer conversation.<br>A CLI is great for engineers. It is not the right surface for a customer success or operations team asking data questions all day.<br>What I Built¶<br>Byaan is what sits between a CLI and a SaaS.<br>A small harness built on the OpenAI Agents SDK<br>A read-only wrapper that blocks DDL and DML at the execution layer, so the agent is incapable of mutating your database<br>A UI that shows the generated SQL, the result, the chart, and lets...