A growth-stage SaaS company had four years of rich user data, but nobody was using it. Why? Because extracting a single insight required a data analyst, a bespoke SQL query, and a two-day wait. We built a natural-language analytics platform that gave anyone instant answers. Manual reporting dropped 60% in the first quarter.
Challenge
The analytics bottleneck in growth-stage SaaS is almost always the same: data collection is flawless, but distribution is broken. The data team becomes a request queue. The product team guesses while they wait. The gap between data collected and data used is exactly where growth dies.
Solution
We deployed six interconnected modules—from a governed metrics layer to a natural language query interface—transforming a tangled database into a self-serve intelligence engine.
Result
85%
Analytics adoption rate
Timeline
14-week delivery
5 delivery phases
Team
6 specialist roles
Cross-functional delivery
Evidence
Anonymized
Project and post-launch operating period
Our client was a Series A B2B SaaS company with 180 enterprise customers and 22,000 end users. The engineering founders had instrumented the product beautifully from day one. By year four, they were sitting on a goldmine of user behavior data. The problem was access. Data lived in a fragmented PostgreSQL and warehouse setup. Answering a simple business question required writing SQL—meaning every query bottlenecked at the two-person data team. In the absence of accessible data, massive product decisions were being made on intuition, anecdote, and the loudest customer complaint from the previous week.
Client Operating Profile
Scope, visibility, delivery context, and trust signals
“We have four years of data about everything our users do. We use about 2% of it. The other 98% sits there answering no one's questions because everyone who could answer them is busy building the product.”
Head of Product
Client
Confidential SaaS and B2B Technology client
Reach
India-headquartered, serving India and Southeast Asia
Surfaces
4 platforms
Evidence
anonymized
Client operating details, platform surface area, and validation signals that shaped the work.
Confidential SaaS and B2B Technology client
Anonymized public case study
Series A B2B SaaS company
65 people, including a bottlenecked 2-person data team
India-headquartered, serving India and Southeast Asia
Internal Analytics Dashboard, Customer-Facing Analytics, Slack Integration, Executive Reporting
2019
anonymized
Project and post-launch operating period
Metrics are shown as client-reported or operating-period outcomes; confidential identifiers are removed where required.
The analytics bottleneck in growth-stage SaaS is almost always the same: data collection is flawless, but distribution is broken. The data team becomes a request queue. The product team guesses while they wait. The gap between data collected and data used is exactly where growth dies.
The data team received 23 requests a week but only had the capacity for 14. Product managers waited 3–5 days for sprint metrics. Customer success managers asked for churn risk reports and received them after the client had already cancelled.
The company had 14 legacy dashboards built for highly specific, outdated purposes. Sales was looking at pipeline metrics that no longer reflected their actual sales motion. The dashboards answered the questions of the past, not the present.
The CS team spent two days every month building a massive customer health spreadsheet. By the time it was finished, it was two weeks out of date. Intervening on an 'at-risk' account was structurally impossible because the visibility lag was too high.
Without accessible usage data, product prioritization defaulted to support tickets and vocal sales prospects. The company was building niche features for vocal minorities while completely ignoring the silent majorities struggling with core workflows.
Compiling quarterly board reports required 12 hours of manual exports, VLOOKUPs, and reconciliation across six conflicting systems. The resulting report was error-prone, static, and immediately obsolete.
They bought a heavy, drag-and-drop BI tool. It was powerful, but non-technical staff didn't understand the underlying data models and accidentally joined tables incorrectly. After two major product decisions were made based on wildly miscalculated metrics, confidence in the tool collapsed. They reverted to the data team's manual queue.
"The Head of Product joined from a mature organization where rapid, data-informed experimentation was the norm. She believed in the product, but found an infrastructure that made her job nearly impossible. Fixing this wasn't an operational 'nice-to-have'; it was a rescue mission for the company's product culture."
Before discussing architectures, we spent two weeks interviewing teams. We didn't just ask what reports they needed; we asked what questions they had simply stopped asking because getting the answer was too painful.
We ran structured interviews across product, sales, and CS. We audited the data team's 6-week backlog and analyzed the 14 existing dashboards (six were completely unused; two had known calculation errors). The findings were undeniable: the infrastructure wasn't the root cause. The friction of asking a question was.
The 23 requests the data team received every week weren't the only questions the company had. They were just the ones important enough to justify the friction of filing a ticket. If we could reduce the cost of asking a question to zero seconds and zero SQL, we would unlock a massive shadow-backlog of strategic curiosity.
The 60-Second Rule: Anyone in the company, regardless of technical skill, must be able to get a reliable answer in under a minute. Crucially, a faster way to get *wrong* answers is not progress. Therefore, every single number in the platform had to have a canonical, centrally governed definition.
We deployed six interconnected modules—from a governed metrics layer to a natural language query interface—transforming a tangled database into a self-serve intelligence engine.
A single, governed dbt repository defining every core metric (MRR, DAU, Churn). If the definition of 'Churn' changes, it updates globally. Every dashboard and query references this exact layer.
This cured the 'conflicting board report' problem. When Sales and Product ask for MRR, they get the exact same number. It is the invisible foundation that makes the entire platform trustworthy.
dbt-based semantic layer with version-controlled SQL models. Automated data quality tests run on every refresh, exposing confidence flags to the UI if a pipeline fails.The source of truth: version-controlled, tested SQL models for all metrics
Lightning-fast columnar storage for sub-second analytical queries at scale
Natural Language to SQL engine, trained specifically on the company's schema
Real-time event ingestion and heavy batch processing for historical backfills
Highly customizable, responsive frontend visualization layer
Unified API layer serving both internal dashboards and the customer-facing embedded app
“Because users had been burned by bad data in the past, trust was low. We added a tooltip to every metric showing its exact definition, calculation logic, and last-validation date. In week one, users hovered over them 4,000 times. Once they verified the system wasn't lying, they trusted it implicitly.”
“When you ask a plain English question, the UI returns the chart—but also features an expandable tab showing the exact SQL it generated. Non-technical users ignore it; technical users inspect it to verify accuracy. Transparency builds confidence.”
A shiny natural-language interface wrapped around bad metrics produces confident garbage. We spent the first three weeks painfully defining the business's core math before writing a single line of UI code.
Operational Log
Mapped out the 6-week backlog, audited the messy event schema, and finalized a prioritized list of capabilities.
Defined and tested 42 canonical metrics in dbt. Provisioned ClickHouse and successfully backfilled 3 years of historical event data.
Fine-tuned GPT-4 on 500 annotated query examples to build the Text-to-SQL engine. Calibrated anomaly detection algorithms against 12 months of historical data.
Deployed the real-time CS health model. Built the multi-tenant sandbox for the customer-facing embedded analytics layer, clearing strict legal privacy boundaries.
Role-specific onboarding for Product, CS, and Sales. Pair-worked with the 2-person internal data team to ensure they could own and maintain the dbt layer indefinitely.
Deployed Roster
Working Rhythm
The defining moment of the project wasn't code; it was a 3-week workshop with the Head of Product, VP of CS, and CFO. Forcing leadership to agree on what 'Active User' and 'Churn' *actually* meant mathematically was uncomfortable. But locking those definitions into dbt code resolved years of inter-departmental arguments.
Diagnostic Log
Messy legacy tracking. Four years of organic growth meant the same user action was logged under three different event names, depending on who wrote the code.
Instead of rewriting the core application code, we built an event normalization layer in dbt. It mapped all 23 legacy naming inconsistencies into clean, canonical event streams, insulating the new analytics platform from the sins of the past.
The NLQ engine failed on complex comparative queries (e.g., 'Show me accounts where adoption dropped but NPS stayed high').
We ran a targeted annotation sprint, manually mapping 150 complex SQL queries and feeding them back into the fine-tuning dataset. We also added a fallback: if the model's confidence was low, the UI prompted 'Let me verify this with our data team' rather than hallucinating a wrong answer.
The initial Customer Health model was too sensitive, flagging 40% of accounts as 'Amber/At-Risk.' The 7-person CS team was immediately overwhelmed.
We sat down with the VP of CS and had her manually rate the top 50 flagged accounts based on her intuition. We used her human labels to recalibrate the model's thresholds, dropping the immediate alerts from 72 to a highly actionable 18. We added a 'Watch List' tier for the rest.
Operational efficiency spiked instantly, but the business metrics took a few months to mature. When they did, they proved that a company making hundreds of small, data-informed decisions will radically outperform a company running on gut instinct.
active users querying data independently — up from 12%
analyst hours freed from tedious CSV pulls and basic queries
composite improvement across product engagement, retention, and expansion
B2B SaaS Client
Valuable lessons and strategic insights uncovered through this project that inform our future work and architectural decisions.
An AI interface layered over poorly defined metrics produces confident garbage. The painful weeks spent forcing leadership to agree on the exact mathematical definition of MRR was the most valuable work of the project. We refuse to build NLQ interfaces until the dbt metrics layer is flawless.
The company had been burned by bad BI tools in the past. To drive 85% adoption, we didn't just need a slick UI; we needed visible trustworthiness. Tooltips defining calculation logic, visible underlying SQL, and automated pipeline tests rebuilt their trust through radical transparency.
The most valuable data points aren't found in a data team's Jira backlog. They are the strategic questions that PMs and execs simply gave up asking because the friction was too high. Unlocking those 'abandoned' questions is the true ROI of a modern analytics platform.
Running a SaaS business where your data team is a bottleneck and your product decisions are running on instinct? The data to make better decisions is already there. What's missing is the infrastructure to unlock it.
We build analytics platforms for SaaS companies where the data exists, but the access doesn't. Tell us about your current data infrastructure and the decisions you wish were better informed. We'll give you an honest view of what's buildable.
"No generic BI vendor pitches. A real conversation about your data and decisions."