The problem
The client is a two-person founding team with a SaaS idea: a natural-language analytics tool for e-commerce operators. Instead of a dashboard with preset charts, a user could ask "why did returns spike in the Pacific Northwest last month?" and get an answer grounded in their actual store data. Neither founder was a backend engineer; they needed the product built from zero, not a feature added to something existing.
The product's core technical bet was also its core risk: could natural-language querying over structured e-commerce data be accurate and fast enough to trust, at a cost per query low enough to support a reasonable subscription price? If that bet was wrong, there was no fallback feature to hide behind. That shaped the build differently from an "AI feature added to an app": the AI accuracy and cost model had to work before anything else about the product mattered.
Why we scoped the model architecture before the UI
Most new product builds start with UI and user flows. We deliberately reversed that and spent the first two weeks purely on the query-to-answer pipeline, using a command-line prototype with no interface at all. If that core mechanism didn't work reliably and affordably, no amount of UI work would save the product. That's what "AI-native" actually means: the architecture is built around what the model needs to do its job well, not around a UI that AI gets bolted onto afterward.
Architecture
Text-to-query, not text-to-answer
The core design decision: the model does not generate answers directly from raw data. It generates a structured query (effectively parameterized SQL against a defined schema) which executes against the actual database, and a second pass formats the real query results into a natural-language answer. This two-step design exists specifically to stop the model from ever inventing a number. It can get the query wrong, which is visible and correctable, but it can't hallucinate a return rate that never happened, because every number comes from an actual query execution.
Schema-aware prompt construction
Each customer's store schema (which product fields exist, how returns are tracked, what custom attributes they use) is different, so the query-generation prompt is built dynamically per customer from their schema metadata rather than one fixed prompt for everyone. This was the single largest source of accuracy improvement during the build, more than any change to the underlying model.
Cost-aware model selection
Query generation (the harder reasoning task) runs on a stronger model; answer formatting (turning query results into readable text) runs on a smaller, cheaper model, because that step doesn't need the same reasoning capability. This split kept the average cost per query at $0.09, a number the founders needed to confirm before setting subscription pricing, and it came directly from not using one model for the whole pipeline.
Full-stack build
With the core pipeline validated, we built the full product: a Next.js frontend, the query and formatting pipeline as backend services, usage-based billing integration, and onboarding flows for connecting a store's product catalog. Launch support included the first month of production monitoring and rapid fixes as the initial design partners started using it against real, messier-than-expected data.
Challenges and tradeoffs
- Real customer data was far messier than our test schemas. Design partners had inconsistent product categorization, duplicate SKUs, and years of legacy data with different field conventions than newer entries. We added a schema-normalization step ahead of query generation because our clean test data hadn't prepared us for this, which cost about a week of rework mid-build.
- Latency budget was tight for a "conversational" feel. The two-step query-then-format pipeline added latency compared to a single-pass approach. We parallelized formatting with a secondary lightweight query wherever possible and kept the median at 1.8 seconds. A small share of complex multi-condition questions still take closer to 4 seconds, which the founders accepted as a known tradeoff rather than a launch blocker.
- Prompt injection through store data was a real, not theoretical, risk. Customer product descriptions and custom fields feed into the schema context, so we had to treat that data, not just the user's question, as untrusted input to the prompt. A pre-launch security review found the issue, and we added sanitization for it before launch.
Results
The product launched eleven weeks after the initial scoping conversation, with the core query pipeline validated in the first two weeks, before any UI work began. Forty design partners, recruited from the founders' network, were using it at launch, with a median query-to-insight time of 1.8 seconds and an average cost per query low enough to comfortably support the subscription price.
The founders have since described validating the core pipeline before building any UI as "the thing that kept us from building a beautiful dashboard around a broken engine." Two other AI features they'd sketched during planning turned out to have accuracy problems that only surfaced against real, messy data, and they were caught before any UI time was sunk into them.
What we'd do differently
We'd request real (anonymized) customer data samples from design partners during the initial two-week validation phase rather than after. Testing against our own clean synthetic schemas first meant the messy-data problems surfaced during integration instead of during core pipeline validation, where they'd have been cheaper to fix.