№00
At a Glance
2
Co-Founders
Shipping after hours and weeknds
6
Months, start to stop
February to July 2026
<10
Min
Raw file to working API
Measured on datasets up to ~250,000 rows
2
Pilot users live
Month-long trials, through The Indian Data Club
2
Accelerators accepted
Draper Startup House India and Build3
1
Enterprise VP chasing approval
Oracle India, held up on internal permissions
№01
Long Story Short
Gaur Data is a backend for data applications. Connect your sources, define your metrics once, serve them to dashboards, apps and AI agents through one API key.
Two of us. Akshith built everything technical. I owned the product end to end. Flows, screens, brand, customer conversations, ICP, GTM. Had full time job, so all of it happened at night and on weekends, and my manager at Perficient knew about it.
01
We built it for data engineers.
Then founders with no data team started asking for it, and a lot of them did not know what analytical data even was.
02
So we rebuilt it for them.
An agent that writes contracts from natural language, a plain English layer on every contract, and a chat mode for people who cannot write SQL.
03
Live product, live docs, two pilot users, a VP at Oracle India chasing internal approvals.
Under ten minutes from a raw file to a working, governed API.
04
We stopped in July.
An acquisition offer where the terms did not work, and funding conversations that were not the right fit either. It is going open source.
Then the thing I am proudest of, and it was not a feature.
Two demos in a row went straight over people’s heads. So I stopped demoing Gaur and started demoing things built with Gaur. Everything good after that came from the change.
№02
The Challenge
Make data infrastructure that a data engineer respects and a founder can actually use.
Those two want opposite things.
Engineer
Wants every control exposed.
VS
Founder
Wants three clicks and a number they can trust.
The Constraints
Two people, after hours.
I had full time job.
Bootstrapped.
No investor, every rupee ours.
No design team.
No researcher, no writer, no second designer to argue with.
I am not a data engineer.
I was designing for a job I have never done.
№03
Role, Team, Timeline
Co-Founder and Head of Product Design. 6 months of nights and weekends.
What I owned
Flows
IA
Every screen
Brand
Marketing site
ICP research
Positioning
GTM
Outbound
Social
Half of every customer call
February
Research, competitor analysis, tech events, first conversations
March
April
May
ICP and GTM, flow revamp, the demo change
June 1
Launch, two pilot users, outbound running
July
Acquisition offer, investor conversations, decision to open source
Akshith
Co-founder
Everything technical.
Sahib Musheraff
Advisor, dev rel and community and founder of The Indian Data Club
Both pilots came through him.
Owning all of it meant none of it got the depth a team would have given it. Ten conversations, not fifty. A week on brand, not a quarter. That was the trade, and at this stage I would make it again.
Not mine: the backend, the architecture, any line of production code.
№04
What We Found
10 plus discovery interviews, then continuous feedback after that.
A VP at Oracle India
A CXO at Thoucentric
A contract PM at the University of Horticulture, Bagalkot
The founder of Naandi Ventures
The rest were engineers and advisors at bigger firms. Most came from tech events in Hyderabad and Pune and from The Indian Data Club. Almost none from the internet.
We asked about their work before showing them anything.
Understand their world first, then a glimpse through Try It Live, never a product tour. Once somebody has seen your product they stop telling you about their job and start answering the question they think you want answered.
The assumption that broke.
We were sure only technical people would use this. Instead the people leaning in hardest were founders with no data team at all. Some did not know the difference between raw data and analytical data, so we ended up explaining that before we could explain anything else.
The question we never answered well enough.
Why contracts matter.
It is the whole product and it stays invisible until two teams show up with two different revenue numbers.
Why not just use any AI tool?
Are you a BI tool?
Do we really have to ingest all our business data?
That last one came from everyone senior, and it is why permissions ended up inside the contract and why we offered Oracle an on prem install.
Two things changed the product.
Gaur AI
Someone got through ingestion fine and stalled on defining a contract, too many options on one screen. That became Gaur AI.
Studio
People wanted to look at their data once it was in, not just query it. That became Studio.
The nos were more useful than the yeses.
Five reasons, and only two of them about the product.
№05
The Decisions I Made
Three ICPs instead of one guess.
“Data engineers” is not an ICP, its a job title. Data size was the real filter and Apollo has no filter for that, so I used 50 to 1000 people as a proxy and went bottom up on roles.
The people who feel it, not the people who sign.
01
Customer analytics builders
In product led B2B SaaS.
02
Operational intelligence teams
In logistics and retail ops.
03
AI native builders
Whose agents need governed context instead of raw tables.
The positioning fight.
Akshith wanted to lead with the technical truth, a runtime that does not hallucinate. I wanted the whole infrastructure layer, because the buying problem is not hallucination, its five subscriptions and a data team doing work nobody wants to be doing. I backed it bottom up. Add up what one target customer already spends on BI licences, tools, data team hours and engineering time.
That budget already exists, so nobody has to create a new line item or hire anyone to buy us.
Before
“The Analytical Runtime for Production Systems”
After
“The Default Backend for Building Data Applications.”
It got settled by the demos and the conversations, not by either of us winning. Its not like I won but we as a business did and that’s what matters end of the day.
Three ways to build the same contract.
A contract is the single source of truth, so how you build one decides who can use the product at all.
JSON editor
Version one was a JSON editor with a slash command menu. Clean, fast, and completely dependent on already knowing what a dimension is.
Visual builder
Feedback killed it, so I added a visual builder on the same five groups the JSON already has.
Gaur AI
Then Gaur AI on top of both.
All three stayed. Gaur AI is upfront because it serves the most people. The visual builder and the JSON editor sit two steps in, for anyone who does not want to trust an agent, and for the power user who just wants to type.
Ask mode and Build mode.
Originally
Originally the chat picked the model itself, which added a delay to every answer and meant a simple question could quietly burn credits.
The split
Build runs a heavier model and costs more credits. The split is slower to explain, but nobody gets surprised by a bill.
The agent asks before it builds.
An agent that quietly writes your source of truth is a scary thing to ship, so it never does. You say what you want, it comes back with a few questions in plain English, then a build plan in one sentence, the JSON below it, and Create as a separate click.
What I cut.
Workflows and automations.
Example, watch the inventory table, notice a shortage, notify the store or place the order itself. Good feature. Would have eaten a month or two which we did not have.
№06
What Broke
Two demos in a row, and both went over their heads.
The first was with someone from The Indian Data Club. I walked through Gaur properly. Ingestion, collections, models, contracts, consumers. They barely followed any of it. Then the same thing happened at an event a week later. Same walkthrough, same blank reaction.
The problem was not the product and it was also not them. Nobody gets excited about a layer. They get excited about the thing sitting on top of it, but I kept showing them the layer.
So we stopped showing Gaur.
Before
I was demoing infrastructure.
After
I built a fake company instead.
SaaS HQ
A fictional enterprise with its own internal analytics
Usage trends, monthly revenue, upgrade leads. A dashboard people could look at and a chatbot they could type into and get real answers from. All of it running on Gaur contracts, none of it looking like Gaur.
Try it Live, powered by Gaur Data.
Akshith did the same on the marketing site. Try It Live, a chat box answering questions against a sample dataset, powered by our own API key. We were the first customer of our own backend.
After that we led with those two and never opened the actual product unless somebody asked. People got it immediately. That is what Oracle saw. That is what got us both pilots.
The lesson is narrower than “show don’t tell”.
If you sell infrastructure, your demo is not your product. It is somebody else’s product with yours underneath.
№07
Where It Landed
Four steps, and the contract sits in the middle of all of them.
01 · INGEST
Postgres, MySQL, SQLite, Cloudflare D1, Snowflake, Stripe, S3, R2, or drop in CSV, Excel, Parquet, JSON. Webhooks for events that land as they happen. Schedule any of it to refresh on its own.
02 · EXPLORE
Shape raw tables into models, query them, or ask in plain English.
03 · DEFINE
Build a contract. Sources, dimensions, measures, filters, row level security. By agent, by form, or by hand.
04 · CONSUME
Turn it into an API key. REST, an OpenAI compatible chat endpoint, an MCP server, read only SQL.
Under ten minutes
from a raw file to a working API, on datasets up to around 250,000 rows. We measured it, it was not a guess.
Everything above is live. Studio, the dashboard builder, is not. Test users saw it in a prototype and it tested well, then we ran out of runway before production.
№08
Details I Sweated
Permissions live in the contract, not in the dashboard.
Row level security is a design decision as much as an architectural one.
The normal way is every dashboard, app and export carries its own access rules. So the rules drift, and nobody can tell you who can see what without opening five tools and asking three people.
Put it in the contract and it holds everywhere the contract goes. One of our pilots had several sources and needed different permissions per team, marketing seeing campaign numbers but not revenue, and wanted external dashboards without writing glue code for any of it. They chose us over PowerBI mostly for that.
“Who should see the data?” is row level security asked in a way a founder can answer.
That one line does more for a non technical user than any amount of tooltip writing would have. Early on it asked everything every time, including RLS for people who did not need it. Made it progressive instead.
Same idea runs through consumption. REST, chat, MCP and read only SQL all pull the same contract. So the number on the customer dashboard, the number the internal agent gives, and the number in the board deck are the same number, and you can point at where it came from.
The contract page keeps every single control.
The first draft of the visual builder was a wall. Fifty plus dropdowns, toggles and fields on one screen, and it was genuinely all needed. That is what a contract is.
The obvious move is to cut things. I did not cut anything. The page follows the five groups the JSON already has, because that is how it is built underneath. Each group collapsed by default with an add button. You open what you need and ignore the rest.
Same information, same power, one screen instead of a wall. A power user can still skip it and type JSON. Nothing was taken away from anyone.
Contracts: Visual view on top, JSON view bottom.
Paper first, then the build tool.
Flows, IA and hierarchy were worked out on paper. Then I described the structure to Claude Design and Claude Code and got production ready screens out of it, so almost the whole product was built that way with no Figma stage at all.
That is the only reason we were in market by the start of June. For a product this size, designing it the traditional way would have taken the three months on its own. The structural thinking did not change, only where the output came from. Chat, the contract builder and Studio each went through at least two full rebuilds.
Few initial paper sketches.
A plain English layer on every contract.
The Context tab is the same contract written for a human. Terms, rules, use cases in full sentences. You write it or Gaur AI generates it. Small thing, and it carries the non technical user. It also feeds the agent, so your team and your chatbot read the same explanation.
Foundations by hand, components by tool.
Logo, palette, type scale, voice took a full week of my own work. The component library on top of it took a day. Get the foundation wrong and everything built on it cripples.
The brand.
The Gaur is the Indian bison. Strong, robust, moves with intent. Four versions before we settled. Terracotta for Indian soil, a monospace face for the terminal feel, ink and bone holding the page.
The bison walks left, never gets rotated, never gets a drop shadow. Small rules, but two people ship fast and inconsistently unless somebody writes them down.
People brought the brand up unprompted in almost every conversation. It is why we were recognizable at events with 170 followers and no funding.
Palette
Typeface
Tone
Mascot
What I did not repeat.
At LPL I opened a design system rebuild by spending a week defining tokens exhaustively, and my VP told me the order was wrong. So this time, no full design system. Icons, logos, styles, the components we actually needed, nothing else. Notes on LPL Design System.
№09
What It Added Up To
Real:
Two pilot users through The Indian Data Club, on a month long trial.
A quick commerce startup running inventory and internal analytics. An engineer at a mid size firm who replaced PowerBI
A VP at Oracle India far enough along to be chasing internal approvals
Accepted into two accelerators, Draper Startup House India and Build3
Live product, live docs, a marketing site,
10 to 15 waitlist signups, around 20 unique visitors a day
Not real: revenue. Zero.
Both pilots said they were willing to pay for a subscription. We did not get to find out if that was true.
The channels we worked hardest on returned the least.
How it ended. July, all at once. An acquisition offer where the terms did not work for us. Investor conversations that were not the right fit either. One accelerator wanted a fee we could not justify, one wanted revenue we did not have yet, and the one with no blocker moved its start date from late July to late September. We had funded it ourselves the whole way, so without a deal that fit there was no way to carry it into the next stage alone.
We told both pilots the truth and that it would be open sourced. They were fine with it, and relieved it was not just disappearing.
Two people, nights and weekends, no outside money.
A product that works end to end, users who wanted to pay for it, and an enterprise pipeline. The reason it stopped was terms and funding, not the thing we built.
№10
What I Would Do Differently
01
Demo the value, not the layer.
Two months of conversations lost before I worked this out. SaaS HQ should have existed in March.
02
Skip outbound entirely.
Six weeks and roughly nine thousand emails for three meetings. The evidence was in front of me by week two.
03
Ship the small thing that unblocks people.
Studio tested well and I let it sit behind bigger work until there was no runway left to ship it.
Every good thing that happened here came after I stopped explaining and started showing.
The product held up. Two people built something an enterprise was ready to buy, and it stopped for reasons that had nothing to do with whether it worked.