Etorial
A trust-first AI platform serving aviation parts commerce. Four surfaces, one architecture. Replacing the Gmail-and-spreadsheet operating model for a production client.
The Problem Isn’t Just Hallucinations. It’s That Brokers Don’t Have an Operating System.
Aviation parts brokers run their business across four disconnected surfaces: Gmail for RFQs, spreadsheets for inventory, marketplace logins for sourcing, and phone calls for everything else. There is no system of record. Every deal is a manual re-assembly of information scattered across tools that never talk to each other.
Most AI products in this space drop a chatbot on top of that chaos and call it transformation. It isn’t. A chatbot that reads from a spreadsheet inherits every error in the spreadsheet, and a language model that guesses a part number in aviation can cost someone their job, their contract, or in rare cases their safety.
The opportunity was bigger than a single feature. It was to build the operating layer itself, a trust-first platform where every surface a broker touches runs on the same verified data, with the same architectural guarantee: the AI never guesses, and code handles every lookup.
Etorial was built for smaller brokers. Larger companies can afford custom tooling, dedicated ops teams, and enterprise platforms that stitch the chaos together. Smaller shops, often covering procurement, sourcing, inventory, and customer service at once, cannot. That’s where the disconnected operating model hurts most, and that’s where the opportunity was clearest.
Founder-Operator
I own every layer of Etorial: product strategy, system architecture, conversation design, backend engineering, QA methodology, client onboarding, pricing, and go-to-market. Etorial is a solo operation by design. Every decision, from database schema to launch gate, runs through me.
That scope is a deliberate choice, not a resourcing constraint. Running it solo forces systems thinking: when one person makes every call, there is nowhere to hide an inconsistency between the design, the architecture, and the operating model. The product has to be internally coherent or it does not ship.
Building this solo meant building two operating systems at once. One is the product Turbana runs on. The other is the operating model Etorial itself runs on. Same principles in both: documented decisions, written rules, QA-first deployment, no silent failures. The discipline the product promises clients is the discipline the company operates by.
The stack: Firestore for real-time data, Google Cloud Run for the MCP server and rules engine, Anthropic’s Claude API with Model Context Protocol for all language generation, Firebase Auth for the operator portal, and Netlify for client-facing surfaces. Voiceflow was retired as part of the Phase 2 migration.
One Client. Four Surfaces. One Architecture.
Turbana Solutions, a Tampa-based aviation parts broker, is the anchor client. The expansion arc moves from front-door to full execution layer, with each surface built on the same trust foundation, each phase gated on performance of the last.
Buyer Chat
Quote requests, inventory lookup, and lead capture on turbanasolutions.com.
LiveInventory Management
Live parts database and operator management interface. The data foundation every surface reads from.
LiveRFQ Inbox
AI email processor and six-state operator portal replacing the Gmail workflow.
LiveTransactional
Payment capture, shipping, and parts storage. Closes the commerce loop end-to-end.
On RoadmapTrust Architecture, Applied Four Ways
The architectural thesis is simple and non-negotiable: code handles every data lookup. The language model never searches, never infers, never sources. Every surface is just a different interface to the same trust layer. This is why the platform scales without accuracy degrading as the surface count grows.
The architecture is deliberately boring. Boring is what makes it scale.
What I Chose and Why
Most of these decisions traded flexibility for trust. In aviation, that trade is the right one every time.
-
1
Trust Architecture as a pattern, not a claim
Separation of search and language is enforced structurally, not through prompt engineering. Deterministic code performs every data lookup. The language model only receives verified, structured results and formats them. This isn’t a promise the AI keeps. It’s an architecture where inaccuracy is structurally difficult.
-
2
Zero-inference policy over graceful guessing
If data is missing, the system returns “Not provided.” A confidently wrong answer is treated as a SEV-1 blocker. In aviation this is a safety and liability line, not a UX preference. I chose visible gaps over helpful fiction every time.
-
3
Human-in-the-loop at every commit
The AI retrieves, parses, and drafts. It doesn’t commit. Inventory edits route through the operator because inventory is the source of truth every surface reads from. Drafted replies route through the operator because a quote is a contractual statement. When a buyer asks for a human, the AI hands off immediately. Automation accelerates the work. It doesn’t replace the judgment.
-
4
Scale-first architecture over single-tenant convenience
The next client onboards with a configuration change, not a rebuild. Single-tenant hardcoded references are labeled as tech debt with retirement dates, not treated as invisible. The platform was built to carry multiple clients from day one.
What Runs on the Platform
Each surface solves a discrete broker problem. Together they add up to a replacement for the Gmail-and-spreadsheet stack. Each one is built on the same trust layer.
1. Buyer Chat: The Gateway
LiveThe front door. When a buyer lands on turbanasolutions.com, the chat handles quote requests, inventory lookup, and lead capture. Real-time data, conversational interface, no waiting for a human to get back to you. The sales team sees every conversation, every lead, every query in a unified dashboard.
Sales Dashboard: Every conversation, captured lead, and inventory query surfaces in real time for the Turbana team. No context is lost between the AI agent and the human sales team.
Operator dashboard shown in QA environment (fictional operator “Sandpiper Air”) to protect anchor client data.
Lead Capture
Conversation Transcripts
Expanded Conversation View: Operators open any transcript to see the full exchange between buyer and agent, message by message, with timestamps and context preserved.
Expanded conversation shown in QA environment (fictional operator “Sandpiper Air”) to protect anchor client data.
2. Inventory Management: The System of Record
LiveEvery surface reads from the same inventory. That inventory needed its own operator interface, a system of record where parts, pricing, conditions, certifications, and counts are maintained by the broker directly, not reverse-engineered from spreadsheet exports.
The inventory management surface is the data foundation the other three surfaces sit on top of. The buyer chat queries it. The RFQ Inbox reconciles incoming requests against it. The transactional layer, when it ships, will commit against it. One source of truth, four interfaces.
Parts inventory shown in QA environment (fictional operator “Sandpiper Air”) to protect anchor client data.
3. RFQ Inbox: The Deal Flow Engine
LiveThis is where the platform replaces the hardest part of a broker’s day: sitting in Gmail, reading RFQs from marketplaces and trading partners, cross-referencing inventory, and hand-drafting replies. The RFQ Inbox is an AI-powered email processor plus a six-state operator portal. Incoming RFQs get parsed, matched against inventory, classified by sender trust, and either auto-drafted, draft-assisted, or routed for manual handling.
It’s the flagship surface. It’s also where the most operating-model discipline lives, not because the code is more complex, but because the stakes of getting a quote wrong are higher.
RFQ Inbox queue shown in QA environment. Four of the six portal states visible in real traffic: Ready, Flagged, No Match, Skipped.
RFQ detail: auto-drafted reply, matched inventory record, attached estimate PDF, and operator Send/Skip action. Human-in-the-loop at every commit made visible.
The Six-State Portal
One portal. Six states. Each state has a locked interaction model, written and approved before build. The operator never has to ask what a record means. The state tells them, and the visual treatment backs it up.
Ready
Parsed, matched, ready for operator action. Opens in a slide-out panel so the queue stays in view.
Quoted
Reply sent. Terminal state. Visually distinct so sent work never gets confused with open work.
Declined
Operator chose not to quote. Recorded with reason. Terminal.
Skipped
Deferred, not declined. The operator can return to it later. Terminal by intent.
Flagged
System flagged the request for human review. Failure mode surfaced, not hidden.
No Match
Parsed correctly, but no inventory match. Visible, actionable, not silently dropped.
4. Transactional: Closing the Loop
Phase 4 · On RoadmapThe last leg closes the commerce loop end-to-end. When a buyer accepts a quote, the platform handles payment capture, shipping coordination, and parts storage. These are the three things that currently live in a tangle of external tools, phone calls, and paper receipts.
Phase 4 is gated on the performance of Phases 1 through 3. It is the difference between Etorial being three useful tools and Etorial being the operating layer Turbana runs on. When it ships, the broker no longer leaves the platform to complete a deal.
What We Delivered
| Before Etorial | After Etorial |
|---|---|
| Quote response: 24–48 hours | Under 10 seconds |
| Inventory lookup: manual spreadsheet search | Real-time Firestore query |
| Lead capture: email or phone only | Automated with full context |
| After-hours coverage: none | 24/7 AI agent |
Two Axes of Scale
Growth happens in two directions. Deepen the relationship with the anchor client. Broaden the client base with the same architecture.
Deepen: Phase 4 at Turbana
Transactional layer: payment, shipping, storage. Closes the commerce loop and makes Etorial the operating layer, not a set of tools bolted to it. Gated on Phase 1 through 3 performance.
Broaden: Next Client via Config
The scale-first architecture is the promise. The next client onboards through configuration, not a rebuild. If that promise holds, the platform has a real path to scale across many clients without linear engineering cost.
What I Learned
You can’t promise a language model will behave. You can only build a system where misbehavior is structurally hard, enforced by code instead of prompts. That meant intentionally limiting what the AI does: no improvising, no answering outside its data. In high-stakes industries, what the AI refuses to do matters more than what it can do.
The QA-first rule and the G1 through G6 gates came from incidents, not from day-one planning. The difference between an amateur operation and a production platform is whether those lessons get written into the system or stay as good intentions.
A chatbot is a feature. A vertical AI OS is a commitment to every surface a company touches. That framing changes how you sequence, how you architect, and how you talk to the client. It also changes what you refuse to ship.
Most AI products sit as a bubble in the corner of a static site. We tested that pattern against several CTA and panel treatments with real users before landing on the current slide-out. The chat should feel like how the business operates, not something bolted on. The intelligence is the product. The website is a surface the product renders through.
What I Would Do Differently
I would have dug deeper into the chatbot industry and how distribution actually works before building the product. The AI-for-SMB market is gatekept: platforms, integrators, and vertical partners decide which products reach operators. Automotive in particular has a long-entrenched version of that landscape, and any outside product has to earn its way in. Six months of earlier research on the access layer, not the technology layer, would have saved GTM time and shaped pricing, packaging, and partner strategy differently. The product thesis was always clear. The path from product to market was the part I had to learn the hard way.
Want to talk about this work?
I’m always open to discussing vertical AI platforms, trust-first architecture, or what it takes to ship production systems that earn the right to expand.
Get in Touch