Skip to content

Current Thesis

Status: Product decision + hypothesis Validation status: Research-supported with initial customer-described use cases; artifact examples, buyer, and willingness to pay still unconfirmed

The current decision is to validate Release Readiness / Engineering Data Readiness as RapidDraft's first pivot wedge. This page keeps the thesis blunt enough to guide action without pretending the market has fully answered.

Decision

Use Release Readiness as the first packaging to validate, but let customer discovery decide whether the first SKU is drawing completeness, ERP/CAD metadata completion, engineering search, or design reuse.

RapidDraft should test whether mechanical teams will pay to make engineering data reliable before it is released, reused, purchased, manufactured, costed, reviewed, or handed into ERP.

July 2026 Discovery Update

Customer and expert calls add evidence for ten related use-case clusters:

Cluster Customer signal Thesis impact
Drawing setup standards Volocopter: NX layers, dimensions, reference sets, validation targets vary by engineer validates drawing standards as an automatable wedge
Geometry/dimension part search Volocopter: PLM search is metadata-only; engineers need geometry/dimension search and ERP search expands from release checks into engineering search/reuse
Requirements-driven review Rohde & Schwarz: functional review misses requirement/guideline checks strengthens standards and intent layer
Custom-to-order design reuse Bauer: senior engineers map non-standard requests to past machine designs from memory validates historical/design-memory moat
Drawing standards and completeness Avilus: drawings should be checked against company standard; missing dimensions, surfaces, material, and bend parameters appear in notes validates drawing standards plus release completeness for Teamcenter-style workflows
Stress input readiness Deutsche Aircraft / Jose: stress engineers spend most time gathering inputs; wrong loads were used when the correct report was lost expands Engineering Data Readiness into analysis-input provenance
Drawing completeness and release cycles Deutsche Aircraft / Evgeny: CATIA/3DEXPERIENCE drawings loop through manual checks before SAP release validates Release Readiness most directly and adds a second Deutsche Aircraft lane
Machine-aware DFM and costing Ulrich: DFM must account for real machine park and quantity sharpens DFM from generic checks to shop-specific rules
Material, AM, CO2 review Dennis Schmitz: material library, AM orientation, CO2, rendering, STEP bug feedback expands review beyond geometry into material/process context
ERP/CAD master data Theegarten/Bauer signal: ERP and CAD metadata maintenance is painful suggests a boring but potentially high-value Engineering Master Data Assistant

Core Problem

Mechanical engineering data sits between engineering intent and downstream execution. When drawings, BOMs, CAD metadata, PLM records, ERP master data, requirements, or manufacturing rules are wrong or incomplete, the cost is paid by manufacturing, quality, procurement, suppliers, ERP/master-data teams, program managers, and customers.

There are two different problems inside that boundary:

Problem type Example Strategic meaning
Consistency / completeness Drawing Rev C vs BOM Rev B; missing STEP file; blank ERP item group Useful wedge, often automatable, not highly defensible
Engineering judgment A shaft drawing is internally consistent but the bearing seat has no fit callout Possible moat if customer-specific judgment can be captured and trusted
Search / reuse A senior engineer knows which previous design fits a custom request, but juniors cannot find it strong design-memory and PLM-intelligence wedge
Master data CAD has geometry/material context, but ERP needs many manually completed fields boring, budget-adjacent, and likely easier than full drawing automation

The hard product problem is not only "compare fields." It is learning what right means for a specific company's release decision.

Wedge And Moat

Wedge Possible moat
Name Release Readiness / Engineering Data Readiness Company-specific engineering judgment and design memory
First promise Do not release, reuse, or hand off bad engineering data Preserve and operationalize how this company decides what is right
Buyer language drawing completeness, master data completion, handoff readiness, engineering search, RFQ readiness, PPAP readiness, ERP cleanup Not sold directly at first
First data drawing PDFs, BOM exports, file inventories, metadata exports, part records, requirements, customer requests accepted/rejected findings, family rules, ECO causes, supplier questions, senior comments, prior design matches
Risk Commodity if it stays at simple checks Services trap if every deployment becomes bespoke

The wedge gets RapidDraft into the workflow. The moat can only accrue after customers trust the wedge and feed real release feedback back into the system.

Why This Could Be Big

The valuable boundary is where engineering intent becomes manufacturing, quality, procurement, supplier, and ERP action. Release errors can create scrap, rework, late ECOs, supplier clarification loops, delayed RFQs, wrong quotes, failed PPAP/FAI submissions, blocked ERP items, audit findings, and launch delays.

This could become large only if RapidDraft moves beyond file checking. The low-value version checks drawing/BOM/revision consistency. The useful version prevents bad packages from reaching downstream teams. The high-value version becomes the system that stores and applies each customer's release intelligence:

  • what the company considers release-ready
  • which defects have hurt before
  • which rules apply to which product family
  • which findings senior engineers accept or reject
  • which supplier, quality, manufacturing, or ERP failures recur

If that learning loop becomes real, switching away from RapidDraft means losing institutional release memory.

What The Decision Does Not Mean

  • It does not mean Release Readiness is the final product name.
  • It does not mean the buyer or budget owner is known.
  • It does not mean the first product should be a CAD-to-ERP integration platform.
  • It does not mean the first product should attempt autonomous senior-engineer judgment.
  • It does not mean CAE, part reuse, MBD, or CAD copilots are irrelevant.

Reality Check

The thesis may be wrong.

Failure mode Why it matters
The pain is real but fragmented across too many roles Everyone cares, nobody owns budget
Design engineers like it but cannot buy it User enthusiasm would not equal revenue
The first version becomes custom integration consulting Software margin and repeatability disappear
Customers will not share enough real drawings/BOMs The product cannot learn or prove value
False positives destroy trust A wrong blocker at release is worse than no tool
Incumbents add enough checks PLM/PDM/ERP vendors may absorb simple readiness features
Valuable judgment is too company-specific The moat may be real but not scalable
Founder intuition is upstream-heavy Downstream buyer access must be earned through discovery

The immediate company-building problem is buyer discovery, not more product refinement.

Product Boundary

Start with an upload/export workflow:

  • drawing PDFs
  • BOM CSV/XLSX
  • metadata exports
  • supplier package inventories
  • human-approved findings
  • evidence-backed issue cards
  • release checklist and handoff summary

Avoid first:

  • PLM replacement
  • ERP writeback
  • native CAD editing
  • autonomous release approval
  • generic document chat
  • broad check libraries not tied to buyer pain

Open Questions

  • Which language makes the buyer lean in: release readiness, engineering data readiness, master data assistant, engineering search, drawing completeness, ERP handoff readiness, drawing QA, or PPAP readiness?
  • Is the first buying trigger engineering, manufacturing engineering, quality, procurement, PLM/release coordination, ERP/master-data cleanup, or design reuse?
  • Which single defect is painful enough to anchor the first demo?

Sources