Claude's Corner: Zymbly - AI for the People Keeping Your Plane in the Air

Zymbly builds AI agents that double productivity for aircraft maintenance technicians by automating troubleshooting and documentation. This YC W2026 startup from the former Virgin Atlantic and Airbus team is building a voice-first copilot for the billion-dollar MRO industry - and the moat is real.

9 min read
Zymbly homepage screenshot with Claude's Corner badge

TL;DR

Zymbly builds AI agents that automate the troubleshooting and paperwork that eats half an aircraft technician's day. Their voice-first copilot sits on top of existing maintenance systems and surfaces the right answer from a mountain of manuals - without replacing the human who still has to sign off. The moat is a founding team that has actually run maintenance operations for Virgin Atlantic and Airbus, which is not something you fake.

6.0
C

Build difficulty

TL;DR: Zymbly builds AI agents that automate the troubleshooting and paperwork that eats half an aircraft technician's day. Their voice-first copilot sits on top of existing maintenance systems and surfaces the right answer from a mountain of manuals - without replacing the human who still has to sign off. The moat is a founding team that has actually run maintenance operations for Virgin Atlantic and Airbus, which is not something you fake.

The Wrench Turners Are Drowning in Paper

Every time you board a commercial flight, someone with an Aircraft Maintenance Engineer license spent part of their day fighting through thousands of pages of documentation to figure out why a hydraulic system threw a fault code. Not because they are bad at their job. Because the information architecture of commercial aviation maintenance was designed in the 1980s and nobody fixed it.

The numbers are alarming: a 43,000-technician shortfall is forecast in North America alone by 2027. The global aviation MRO software market is sitting at roughly $9.5 billion in 2026 on its way to $17.6 billion by 2034. Yet the day-to-day experience of the actual technicians - the ones keeping the aircraft airworthy - has barely changed. They are still cross-referencing physical manuals, re-typing information from one system into another, and hunting for parts availability across disconnected catalogues.

Zymbly thinks that is fixable with AI agents. And they might be right, because they built the founding team first.

What Zymbly Builds

The product is a voice-first AI copilot for aircraft maintenance technicians. It sits as a layer on top of whatever enterprise resource planning system an airline or MRO already uses - AMOS, SAP, or anything else - and connects it to the full stack of maintenance documentation: aircraft records, maintenance manuals, service bulletins, airworthiness directives, and parts catalogues.

A technician working on a fault does not need to leave their workflow. They speak into Zymbly, it queries the relevant sources, surfaces the troubleshooting path, tells them what part they need and whether it is in stock, and then converts their voice notes into the compliant documentation that regulators require. That last part - the paperwork - is where technicians lose enormous amounts of time today.

Zymbly also audits technician actions to flag missed steps. Aviation has a concept called "maintenance-induced damage": errors introduced during repair that become the next fault. The system is designed to catch those before they happen, while keeping the human engineer firmly in the loop for final approval.

The business model is B2B SaaS. Customers are airlines and MRO contractors. The end users are licensed maintenance engineers working on aircraft. Deployment is designed to take weeks with minimal disruption, and customer data is encrypted, access-controlled, and - critically - not used to train the model. For an industry where a data breach could compromise safety records, that matters.

The Team Is the Product (At First)

The three founders all came out of Oliver Wyman's aviation practice before starting Zymbly.

Robbie Bourke spent 25 years in aviation - designing structural components at Airbus, then running maintenance operations at Virgin Atlantic as Head of Aircraft Maintenance, then consulting on fleet strategy. He is the person who has actually supervised the work the product automates.

Ben Jacob led Applied AI at Multiverse, a workforce learning platform backed by GV and General Catalyst. He understands how AI gets adopted in regulated, risk-averse organizations - which is the exact challenge Zymbly faces in every sales conversation.

Azmat Habibullah brings a mathematics background from Imperial College and experience building ML models and enterprise software for regulated industries. He is the CTO who has to make the compliance requirements real in code.

This is not a team that read about the problem. Bourke spent a career inside it. That gives Zymbly something a lot of "AI for X industry" startups lack: the ability to walk into a maintenance director's office and talk about the job at the level of someone who has actually done it. That trust closes pilots with airlines.

How It Actually Works

The architecture is a retrieval-augmented generation system tuned for aviation documentation.

Aviation technical manuals are not like other enterprise documents. Aircraft Maintenance Manuals (AMMs), Illustrated Parts Catalogues (IPCs), and Troubleshooting Manuals (TSMs) are structured according to ATA chapter systems and run to tens of thousands of pages per aircraft type. Service bulletins and airworthiness directives update continuously and must be applied at specific intervals. Getting the retrieval right - returning the correct revision, the correct aircraft effectivity range, the correct task card - is an engineering problem, not just a prompting problem.

The voice interface is the right call for a hangar environment. Technicians have their hands on aircraft. They cannot type. A voice-first UX that works in a noisy environment with heavy background acoustics is a harder engineering problem than it looks on paper.

The ERP integration layer is where a lot of startups in this space would hit a wall. Airlines run aging, heavily customized enterprise systems. Zymbly promises deployment in weeks, which means they have either built a clean adapter layer that handles common MRO ERPs, or they are doing it case-by-case and getting better at it. Given the team's consulting background, it is probably a bit of both.

The compliance audit function - flagging missed steps, surfacing required sign-offs - requires understanding the regulatory logic of EASA Part-145 or FAA Part-145 requirements and mapping them to task execution in real time. That is where the domain knowledge embedded in the founding team turns into technical advantage.

The Competitive Landscape

The MRO software incumbent is Veryon, which serves 5,500 customers and 75,000 maintenance professionals across 150 countries. They have their own AI layer now, called Veryon AIRE. But incumbents building AI features inside legacy platforms are structurally disadvantaged against purpose-built AI-native tools: their data models were not designed for it, their UX was not designed for voice, and their customers are locked in by data gravity rather than product love.

Airline operators are also aware that generic AI - technicians using ChatGPT on the shop floor - is already happening, unofficially. A major airline would rather have a compliant, audited, encrypted system than its engineers querying GPT-4 for maintenance advice. That is not a hypothetical: it is a forcing function Zymbly can use in enterprise conversations.

StartupHub.ai data puts this market in context: of the 810 AI copilot companies we track, only 27 are building for genuine industrial verticals where the cost of a wrong answer is measured in safety incidents and regulatory fines, not user churn. That scarcity is itself a signal - and Zymbly is squarely in that 27.

Difficulty Score

Rating how hard this is to build, across five axes:

  • ML and AI (7/10): RAG over structured aviation documentation with version control and regulatory revision tracking is harder than general-purpose document retrieval. Voice recognition in noisy industrial environments adds another layer. The base LLMs are commodity; the domain-specific retrieval is not.
  • Data (8/10): Aviation documentation is some of the most complex structured data that exists. OEM manuals are licensed, not open. Historical defect records are proprietary to each operator. Getting access to the training data and maintaining currency with revision cycles is an ongoing challenge that never goes away.
  • Backend (6/10): ERP integrations are painful but solved problems in enterprise software. The compliance audit logic requires aviation regulatory knowledge but is implementable once you have the right people. Real-time query performance at scale is table stakes for enterprise AI.
  • Frontend (4/10): Voice-first means the traditional frontend surface area is small. The hard parts are voice UX and offline resilience for environments with poor connectivity. The UI itself is not complex.
  • DevOps (5/10): Aviation data security requirements push toward strict encryption and access controls that most SaaS companies never need to implement. Audit logs for every query. Compliance with airline IT security reviews. More overhead than a typical startup, but well-understood requirements.

Overall difficulty: 6/10. The tech is achievable; the domain access is the blocker.

The Moat - What Is Hard and What Is Not

Hard to replicate:

Customer trust in safety-critical environments is not bought with a demo. An airline's maintenance director putting a new AI system in front of their licensed engineers is betting regulatory compliance and physical safety on the product working correctly. Zymbly got their first design partner because Robbie Bourke had relationships at that airline from his Virgin Atlantic years. That relationship flywheel - domain credibility leading to design partnerships, leading to reference customers, leading to the next airline - takes years to build and cannot be shortcut by hiring a few aviation consultants after the fact.

Data access is the other structural barrier. OEM manuals require licensing agreements. Operator historical defect data is confidential and only accessible once you have the customer. Every customer adds proprietary data that makes the system smarter for that customer and creates lock-in without any artificial lock-in mechanism.

Easy to replicate:

The core stack. An LLM, a retrieval layer, a voice interface, and an ERP integration framework can all be assembled by a competent team in six months. The technology is not the moat. The technology is what gets you in the room. What keeps you there is knowing what "normal" looks like on an A320 overnight transit check, and that knowledge lives in Robbie Bourke's head and gets systematically encoded into the product.

Replicability Score: 62/100

This is not a high-replicability play. The data access, regulatory trust, and domain expertise required to be credible in aviation maintenance add up to a genuine barrier. A well-funded team with deep pockets could hire their way into the domain knowledge over two or three years - but Zymbly will have two or three more years of design partnerships and customer data by then. The window is not closed, but it is closing.

The bigger risk is not clones. It is Veryon or another MRO platform incumbent building a voice-first AI layer with enough domain credibility to match what Zymbly is building from scratch. That is a 24-month problem, not a 6-month problem - which means Zymbly has a window to lock in enough design partners that the conversation shifts from "why not just use Veryon" to "why not just use Zymbly."

The aviation maintenance sector employs hundreds of thousands of people globally, runs on decades-old software, and is about to face its worst workforce shortage in history. That is a setup for a company willing to do the hard, slow, trust-intensive work of selling into regulated operators. Zymbly has the team to do it. The only question is whether they can move fast enough to outrun the category awareness they are creating.

© 2026 StartupHub.ai. All rights reserved. Do not enter, scrape, copy, reproduce, or republish this article in whole or in part. Use as input to AI training, fine-tuning, retrieval-augmented generation, or any machine-learning system is prohibited without written license. Substantially-similar derivative works will be pursued to the fullest extent of applicable copyright, database, and computer-misuse laws. See our terms.

Build This Startup with Claude Code

Complete replication guide — install as a slash command or rules file

# How to Build a Zymbly Clone with Claude Code

A step-by-step guide for developers who want to build an AI-powered voice copilot for a regulated industrial vertical.

---

## Step 1: Database Schema

You need three core data domains: the document corpus, the operator context, and the audit trail.

```sql
-- Document corpus (aviation manuals, service bulletins, etc.)
CREATE TABLE documents (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  operator_id UUID REFERENCES operators(id),
  doc_type TEXT NOT NULL, -- 'AMM', 'IPC', 'TSM', 'SB', 'AD', 'defect_record'
  aircraft_type TEXT NOT NULL, -- e.g. 'A320-200'
  ata_chapter TEXT, -- ATA chapter reference
  revision TEXT,
  effective_date DATE,
  content TEXT NOT NULL,
  embedding VECTOR(1536), -- pgvector for semantic search
  source_metadata JSONB,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Operator context (airline/MRO fleet and configuration)
CREATE TABLE operators (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  erp_type TEXT, -- 'AMOS', 'SAP', 'Ramco', etc.
  erp_connection_config JSONB, -- encrypted connection details
  fleet JSONB, -- aircraft registrations and types
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Technician sessions
CREATE TABLE sessions (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  operator_id UUID REFERENCES operators(id),
  technician_id UUID NOT NULL,
  aircraft_registration TEXT,
  work_order_id TEXT,
  started_at TIMESTAMPTZ DEFAULT now(),
  ended_at TIMESTAMPTZ
);

-- Audit trail (every query, every action)
CREATE TABLE audit_events (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  session_id UUID REFERENCES sessions(id),
  event_type TEXT NOT NULL, -- 'query', 'doc_retrieved', 'action_flagged', 'doc_signed'
  payload JSONB NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Index for vector similarity search
CREATE INDEX ON documents USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);
CREATE INDEX ON documents(operator_id, aircraft_type, doc_type);
```

---

## Step 2: Document Ingestion Pipeline

Aviation documents come in PDF, XML (ATA iSpec 2200), and proprietary formats. Build an ingestion pipeline that handles them all.

```python
# ingestion/pipeline.py
import anthropic
from supabase import create_client
from typing import Literal

client = anthropic.Anthropic()

DocType = Literal['AMM', 'IPC', 'TSM', 'SB', 'AD', 'defect_record']

def chunk_aviation_doc(raw_text: str, doc_type: DocType) -> list[dict]:
    """Split aviation docs at natural boundaries: task cards, procedures, chapters."""
    # Use Claude to extract structured chunks with ATA chapter references
    response = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=8096,
        system="You are an aviation documentation specialist. Extract structured chunks from this document, preserving ATA chapter references, task numbers, and effectivity ranges.",
        messages=[{
            "role": "user",
            "content": f"Document type: {doc_type}\n\nContent:\n{raw_text[:50000]}"
        }]
    )
    # Parse response into chunks with metadata
    return parse_chunks(response.content[0].text)

def embed_and_store(chunk: dict, operator_id: str, supabase_client):
    """Embed a chunk and store with metadata."""
    # Use text-embedding-3-small or equivalent
    embedding = get_embedding(chunk['content'])
    supabase_client.table('documents').insert({
        'operator_id': operator_id,
        'doc_type': chunk['doc_type'],
        'aircraft_type': chunk['aircraft_type'],
        'ata_chapter': chunk.get('ata_chapter'),
        'revision': chunk.get('revision'),
        'content': chunk['content'],
        'embedding': embedding,
        'source_metadata': chunk.get('metadata', {})
    }).execute()
```

---

## Step 3: Retrieval Layer with Aviation-Aware Ranking

Generic cosine similarity retrieval will return wrong results on aviation docs. You need effectivity filtering (does this procedure apply to this specific aircraft serial number?) and revision currency checks.

```python
# retrieval/aviation_rag.py

def retrieve_for_query(
    query: str,
    operator_id: str,
    aircraft_registration: str,
    supabase_client,
    top_k: int = 8
) -> list[dict]:
    """
    Retrieve relevant documentation chunks with aviation-specific filtering.
    """
    # 1. Embed the query
    query_embedding = get_embedding(query)

    # 2. Get aircraft type from registration
    aircraft_type = get_aircraft_type(aircraft_registration, operator_id, supabase_client)

    # 3. Vector search with type filter
    results = supabase_client.rpc('match_documents', {
        'query_embedding': query_embedding,
        'operator_id': operator_id,
        'aircraft_type': aircraft_type,
        'match_count': top_k * 2  # over-retrieve, then filter
    }).execute()

    # 4. Filter for current revisions only (never serve superseded docs)
    current = filter_superseded(results.data)

    # 5. Re-rank by ATA chapter relevance if query contains chapter hints
    ranked = rerank_by_ata_relevance(query, current)

    return ranked[:top_k]


# Supabase RPC function for pgvector search:
# CREATE OR REPLACE FUNCTION match_documents(
#   query_embedding VECTOR(1536),
#   operator_id UUID,
#   aircraft_type TEXT,
#   match_count INT
# ) RETURNS TABLE (id UUID, content TEXT, similarity FLOAT, metadata JSONB)
# AS $$ ... $$ LANGUAGE plpgsql;
```

---

## Step 4: Voice Interface for Hangar Environments

The UX challenge is real: hangar environments are loud (jet engines, tools, PA systems). Use a combination of browser-native speech recognition with a noise-cancellation preprocessing step.

```typescript
// voice/hangar-speech.ts

export class HangarVoiceCapture {
  private mediaRecorder: MediaRecorder | null = null;
  private audioContext: AudioContext | null = null;

  async startCapture(onTranscript: (text: string) => void) {
    const stream = await navigator.mediaDevices.getUserMedia({
      audio: {
        noiseSuppression: true,
        echoCancellation: true,
        autoGainControl: true,
        // Request mono audio - less data, faster processing
        channelCount: 1,
        sampleRate: 16000
      }
    });

    // Send 3-second audio chunks to Whisper API for transcription
    this.mediaRecorder = new MediaRecorder(stream, { mimeType: 'audio/webm' });
    const chunks: Blob[] = [];

    this.mediaRecorder.ondataavailable = (e) => chunks.push(e.data);
    this.mediaRecorder.onstop = async () => {
      const blob = new Blob(chunks, { type: 'audio/webm' });
      const text = await transcribeAudio(blob); // Whisper API call
      onTranscript(text);
      chunks.length = 0;
    };

    // Capture in 4-second intervals
    this.mediaRecorder.start();
    setInterval(() => {
      this.mediaRecorder?.stop();
      this.mediaRecorder?.start();
    }, 4000);
  }
}

// The UI should work with one hand - large tap targets, voice confirmation
// of actions, no small text. Mechanics wear gloves.
```

---

## Step 5: Compliance Audit Layer

This is the part most clones skip and then wonder why airlines won't buy them.

```python
# compliance/audit.py
import anthropic

client = anthropic.Anthropic()

AVIATION_REGULATIONS = {
    'EASA_145': 'EASA Part-145 Approved Maintenance Organisation requirements',
    'FAA_145': 'FAA Part 145 Repair Station requirements',
    'CAA_UK': 'UK CAA Part-145 requirements post-Brexit'
}

def check_task_completeness(
    task_steps_completed: list[str],
    work_order_id: str,
    aircraft_type: str,
    regulatory_framework: str
) -> dict:
    """
    Verify a technician has completed all required steps before sign-off.
    Uses Claude with extended thinking for complex regulatory reasoning.
    """
    response = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=4096,
        thinking={"type": "enabled", "budget_tokens": 2048},
        system=f"""You are an aviation compliance expert under {AVIATION_REGULATIONS[regulatory_framework]}.
        Review the completed maintenance steps and identify:
        1. Any mandatory sign-off points not yet completed
        2. Safety-critical steps that appear missing
        3. Required second-person inspections not noted
        Return a JSON object with 'compliant': bool, 'missing_steps': list, 'warnings': list""",
        messages=[{
            "role": "user",
            "content": f"Aircraft: {aircraft_type}\nWork Order: {work_order_id}\n\nCompleted steps:\n" +
                      "\n".join(f"- {step}" for step in task_steps_completed)
        }]
    )

    # Log every compliance check to audit trail
    log_audit_event('compliance_check', {
        'work_order_id': work_order_id,
        'result': response.content[-1].text,
        'model': 'claude-opus-4-7'
    })

    return parse_compliance_result(response.content[-1].text)
```

---

## Step 6: ERP Integration Adapter

Airlines run AMOS, SAP PM, Ramco, and custom legacy systems. Build an adapter pattern rather than point integrations.

```python
# erp/adapter.py
from abc import ABC, abstractmethod
from typing import Optional

class ERPAdapter(ABC):
    @abstractmethod
    def get_work_order(self, work_order_id: str) -> dict:
        pass

    @abstractmethod
    def get_parts_availability(self, part_numbers: list[str]) -> dict:
        pass

    @abstractmethod
    def create_defect_record(self, session_id: str, description: str, disposition: str) -> str:
        pass

    @abstractmethod
    def close_work_order(self, work_order_id: str, sign_off_data: dict) -> bool:
        pass


class AMOSAdapter(ERPAdapter):
    """Swiss-AviationSoftware AMOS ERP adapter via REST API."""

    def __init__(self, base_url: str, api_key: str):
        self.base_url = base_url
        self.headers = {'Authorization': f'Bearer {api_key}', 'Content-Type': 'application/json'}

    def get_work_order(self, work_order_id: str) -> dict:
        import requests
        response = requests.get(
            f"{self.base_url}/workorders/{work_order_id}",
            headers=self.headers,
            timeout=10
        )
        response.raise_for_status()
        return response.json()

    # ... implement other methods


class SAPPMAdapter(ERPAdapter):
    """SAP Plant Maintenance adapter via RFC or OData."""
    # ... SAP-specific implementation


def get_adapter(erp_type: str, config: dict) -> ERPAdapter:
    adapters = {
        'AMOS': AMOSAdapter,
        'SAP_PM': SAPPMAdapter,
    }
    cls = adapters.get(erp_type)
    if not cls:
        raise ValueError(f"Unsupported ERP: {erp_type}")
    return cls(**config)
```

---

## Step 7: Deployment for Regulated Environments

Aviation IT security reviews are thorough. Plan for these requirements from day one.

```yaml
# infrastructure/requirements.yaml

data_security:
  encryption_at_rest: AES-256
  encryption_in_transit: TLS-1.3-minimum
  key_management: HSM or cloud KMS (not environment variables)
  data_residency: must match airline's regulatory jurisdiction
  customer_data_isolation: per-tenant schemas or separate databases
  backup_retention: 7 years minimum (regulatory requirement for maintenance records)

audit_requirements:
  query_logging: every retrieval logged with timestamp, user, aircraft, query hash
  model_outputs: retained for 90 days minimum
  access_logs: immutable append-only log (CloudTrail or equivalent)
  retention: aligned with operator's regulatory retention schedule

deployment_options:
  cloud: AWS GovCloud or Azure Government for US operators; EU regions for EASA
  on_premise: airlines often require this; containerize everything
  hybrid: most realistic for large carriers

soc2_type2: required before most airline procurement
iso_27001: required for EASA operators
pen_testing: annual third-party, results shared with airline security team

# Do NOT train on customer data. This is table stakes trust, not a feature.
# Put it in the data processing agreement, not just the sales deck.
```

**Total estimated build time for an MVP:** 3-4 months with 3 engineers. Getting the first airline to trust it in production: 12-18 months minimum. That gap is the moat.
claude-code-skills.md