July 2026 — TryHand / Scopelytics AI
hieunvtryhand
July 24, 2026 · 12 min read
It is a scenario universally recognized by anyone in software development: You just wrapped up a grueling two-hour client discovery meeting. Zoom recorded the transcript, the PM jotted down high-level bullets, the BA sketched out frantic mind maps, and then the engineering team asks the defining question: "So, what fields actually go on this screen?"
The response is usually a collective, uncertain silence.
At this stage, system requirements are scattered across conversational prose, the language used is unstandardized, and feature boundaries remain incredibly blurry. Moving from a raw, unstructured transcript to a comprehensive screen definition spec—something developers can actually look at and code against—typically takes anywhere from a few days to several weeks. Worst of all, even after that manual grind, human error still slips through the cracks.
Scopelytics AI was built to close that massive gap. We didn't design it to replace human experts, but to accelerate and standardize the entire pipeline. The platform transforms raw meeting transcripts into feature analyses, maps them directly to design specs, and outputs a highly structured, deliverable .xlsx workbook—all anchored by a rigorous human-in-the-loop review cycle.
This article shares our technical journey from our initial kickoff in March 2026 to our current stable release (v1.1.x). These are our raw, unvarnished lessons on what it actually takes to integrate AI into a B2B SaaS application, and how we learned to use LLMs effectively rather than just slapping an "AI-powered" badge on our marketing site.
The platform’s core architecture stands firmly on three operational pillars:
| ---------------- | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|---|---|---|
| Phase | What the User Does | What the System Does |
| 1. Ingestion | Upload raw transcripts, audio, or video files directly from Zoom, Google Meet, or Microsoft Teams. | Multi-language text normalization and secure, encrypted cloud storage. |
| 2. Analysis | Review AI-generated results, make manual corrections, and confirm structural boundaries. | Extract core features, distinct action items, effort estimations, and exact textual evidence grounding. |
| 3. Output | Preview visual wireframes and download the compiled deliverable workbook. | Automatically generate screen inventories, table specs, design details, and wireframe previews via Google Stitch, bundled into a production-ready .xlsx file. |
Our core architectural differentiator is that both the table specs and design details must be derived from the exact same internal "screen contract." If these downstream pieces aren't bound by a unified schema, the exported spreadsheet will completely mismatch the visual preview layout, instantly destroying user trust.
We began with a lean, linear Minimum Viable Product to test market validation. The pipeline was completely sequential:
Raw Transcript ───> LLM Analysis ───> Design Spec Generation ───> XLSX Export
Our initial tech stack was built on a robust foundation: FastAPI, PostgreSQL, and Redis powering the backend; Next.js 16 and React 19 on the frontend; OpenAI's API handling the cognitive heavy lifting; and Google Stitch driving automated wireframe rendering. The entire system was containerized via Docker and deployed with CI/CD on Google Cloud Platform (GCP). The goal wasn't perfection—it was proving that this end-to-end chain could successfully execute under real-world conditions.
As our first cohort of real enterprise users onboarded, glaring architectural flaws came to light. LLM outputs proved highly erratic across identical runs, visual wireframe previews routinely drifted out of sync with generated Excel files, and our "recall pass" (re-running the prompt to catch missing requirements) was burning massive token volumes without yielding any meaningful quality improvements.
To solve this, we scrapped the linear approach and engineered a multi-stage, secure pipeline:
Plaintext
Raw Input ───> Input Guardrails ───> Semantic Cache ───> Enumeration Pass
───> Dual-LLM Analysis Layer ───> Recall Pass
───> Output Guardrails ───> Normalization ───> Persistence
Transitioning to a Dual-LLM architecture was our single most critical design decision. Instead of forcing a single model to handle everything, we separated privileges entirely: Model A extracts raw facts from the sanitized transcript, and Model B ingests only those structured JSON facts to execute logic. Model B never sees the raw transcript. This strict privilege separation drastically reduced our vulnerability to prompt injections and systematic hallucinations.
In parallel, the Design Spec pipeline evolved into its own deterministic data chain:
Plaintext
Feature Inventory ───> Screen Definitions ───> Data Validation ───> Stitch Render ───> XLSX Assembly
This milestone marked our transition to true enterprise-grade software. We successfully cleared a comprehensive security audit (SEC audit), implementing 36 crucial vulnerability patches. We also established a strict "workflow readiness contract" that perfectly unified data shapes between our analysis and design engines, significantly stabilizing localization and our export layers. Scopelytics AI was no longer an impressive technical demo; it was a production-hardened platform.
Our current sprint focuses heavily on polished system performance. We completely refactored our frontend utilizing TanStack React Query to handle asynchronous polling and Server-Sent Events (SSE) progress counters synced directly with the backend. We also automated Google Stitch API key rotation to handle quota limits gracefully and hotfixed localized caching issues for multi-language visual previews.
To benchmark our system honestly, we ran a thorough internal evaluation across 4 distinct target domains (University Management, E-Commerce, ERP, and LMS), spanning 12 distinct analytical iterations and 12 completed design spec chains. The raw telemetry gave our engineering team a sobering reality check:
While our logs showed that 100% of our asynchronous pipeline runs successfully hit a COMPLETED system status, a look inside the database revealed that only ~42% of those outputs met our strict criteria for production-grade deliverables. The remaining ~58% were flagged as degraded. In fact, for our complex ERP domain test cases, 0 out of 3 runs achieved baseline quality metrics. The lesson is simple: do not trust a COMPLETED status badge—look at your quality telemetry.
Given the exact same client transcript, clicking "re-run" frequently yielded vastly different feature boundaries and timeline estimations. In our complex ERP domain tests, the estimated development effort fluctuated wildly between 12 and 36.5 days an unacceptable 204% variance between the lowest and highest estimates before settling at 25 days. The root cause was our legacy recall logic; it didn't "patch" the existing draft, but completely regenerated the output from scratch, allowing the model to clump modules differently on every run.
Our extraction layer was highly precise, capturing roughly 6 to 11 core features spoken explicitly in the meeting. However, after passing through our best-practice enrichment checklists, the final deliverable swelled to 36 to 51 features. This enrichment is incredibly helpful for software architects, but it presents a major UX hazard: if these inferred features are displayed with the same visual weight as the client's explicit requirements, users mistake AI brainstorming for actual project scope.
A critical architectural flaw we uncovered was that runs flagged as degraded were still allowed to bypass our safety checks, automatically moving to the READY_FOR_REVIEW state and triggering downstream wireframe and Excel exports. Allowing corrupt data to pollute downstream workflows is an open invitation for users to lose faith in your product.
Because large language models know a little bit about everything, they frequently cross-contaminate specialized industries. We watched our University Management module hallucinate Event/Conference features, while our ERP and E-Commerce modules randomly insisted on adding contextually inappropriate voice-command features just because those concepts existed in the LLM's broader training data.
Integrating with Google Stitch for automated UI generation introduced its own unique infrastructure overhead:
Our API key rotation mechanism had to be re-engineered to maintain project/key affinity—ensuring the system never rotates a key midway through a sequential sequence of create/list/generate calls on the exact same resource.
We had to write specific handlers to differentiate between a standard quota exhaustion error and an invalid credential fault, as third-party APIs often obscure both behind a generic HTTP 403 response.
| ----------------------------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- |
|---|---|---|
| Legacy Architecture | Production Architecture (Current) | Core Rationale |
| Single LLM processes raw transcript text. | Dual-LLM chain wrapped in rigid input/output guardrails. | Eliminates prompt injection vectors; cleanly decouples fact extraction from logical reasoning. |
| No intermediate caching layer. | Versioned Semantic Cache mapping prompt and model keys. | Massively reduces API overhead and ensures instant cache invalidation upon prompt updates. |
| Recall pass completely regenerates the output. | Transitioning to atomic, patch-based recall passes. | Keeps upstream Feature IDs static, drastically curbing output variance. |
| UI renders all features in a single flat list. | Visually decouples transcript-grounded requirements from enriched suggestions. | Protects project scope; ensures clear data provenance for business analysts. |
| Frontend polling driven purely by local timers. | Server-Sent Events (SSE) tracking real-time backend progress counters. | UI wireframes render dynamically in real-time as background tasks complete. |
Based on our trials, failures, and ultimate successes, we have codified seven core principles for teams embedding AI into high-stakes enterprise workflows:
Our textual grounding engine achieves an impressive ~81% verbatim match rate against the source transcript. While this represents excellent precision, it does not guarantee complete coverage of an entire meeting. Treat AI output as a highly advanced rough draft; it must pass through a human-in-the-loop review before it ever becomes an official deliverable.
Input guardrails (PII masking, injection filters) and output guardrails (grounding signals, hallucination checks) must run as blocking, synchronous infrastructure blocks. They are there to stop corrupted data from processing—not to simply write an error to your logging platform while letting the broken output slide through to the client.
If the initial meeting analysis layer fails its quality telemetry metrics and is flagged as degraded, the system must freeze the pipeline and prevent the design specification engine from executing.
Never validate your AI product using a single "perfect" transcript crafted in a clean testing environment. We forced our system to run against 4 wildly different corporate domains, evaluating database state changes alongside raw API cost sheets. It was only through this multi-domain stress test that we realized our ERP module was failing completely while our LMS module was highly stable.
AI-driven feature enrichment provides massive value to Business Analysts, but it must be clearly delineated within your UI layout. Never let a client think all 51 features in their technical spec document were explicitly discussed during their alignment call.
Infrastructure metrics—such as cost per run (currently tracking at approximately $0.03/run), absolute latency windows (2–6 minutes), total sequential LLM calls per workflow (21–36 calls), and systemic degradation rates—must be fully indexed, logged, and queryable from your database.
You don't need to force users to manually confirm every minor task. Instead, require explicit human sign-off at these three critical crossroads:
Confirming the high-level screen inventory before triggering micro-design specs.
Reviewing manual correction notes before executing a pipeline retry.
Approving the final technical specification document before passing it to the engineering pipeline.
To optimize the user experience and reduce absolute latency, we implement intelligent batching, processing our automated design spec iterations in parallel chunks of 3 screens at a time. Furthermore, boilerplate screens (such as login, register, or password reset flows) are classified as optional components—the platform presents them as checkable options rather than cluttering the client's core deliverable.
An honest look at our production metrics reveals exactly where we excel and where we are actively refining our platform:
Our Strengths:
Technical Pipeline Stability: 12/12 end-to-end design specification runs successfully compile into clean, uncorrupted file deliverables without system timeouts.
Precision Evidence Grounding: High textual traceability coupled with an optimized operating cost structure (~3 cents per full analysis pass).
Enterprise-Grade Infrastructure: Secure, fully auditable workflow contracts ready for sensitive client deployments.
Our Current Engineering Roadmaps:
Pushing our baseline analysis quality metrics from 42% up past our strict internal target of >80%.
Stablizing our timeline effort estimation matrices within complex enterprise domains (ERP and University Management systems).
Enforcing programmatic quality gates that completely block downstream UI rendering if upstream data metrics read as degraded.
We don't hide our system limitations, because enterprise clients don't need marketing fluff about the omnipotence of AI. They need a partner who understands the boundary lines of LLM capabilities and maintains a structured engineering roadmap to systematically conquer them.
Our journey building Scopelytics AI proves a fundamental truth about modern software development: the actual enterprise value of AI doesn't live in the specific model name listed on your landing page. The value is generated by your pipeline architecture, your human-in-the-loop validation checkpoints, and your willingness to look at your data metrics honestly.
If your company is looking to transform disorganized client meetings into developer-ready technical specifications, or if you want to pilot a highly supervised, AI-assisted business analysis workflow—we are ready to show you how we do it. Bring us an authentic transcript from your last project; we will run it live on our platform and show you exactly where the system anchors to explicit facts, where it suggests best-practice additions, and where human engineering judgment remains entirely irreplaceable.
Scopelytics AI — From meeting to screen spec, backed by evidence.