Skip to content

RapidDraft Studio — Two Build Paths: Fastest vs Best

Source: Architechture & Research/RapidDraft Studio/Vision/Fastest vs Best Vision.docx (March 2026, internal technical strategy) Status: Active — build path decision reference Decision made: Path B2 (Hybrid) is recommended — see Final Recommendation

Framing Principle

If you're not constrained to Code-OSS, you have significantly more freedom to optimise for either speed or long-term quality. The key insight is to not confuse "UI container choice" with "product architecture." You can move fast without painting yourself into a corner if you lock a few core boundaries early.

Path A — Fastest to Market

Goal: Ship a "review + workflow cockpit" that engineers can actually use for DFM + report + collaboration, without pretending you're building CAD.

Stack

  • Web-based (browser-first or lightweight Electron wrapper)
  • WebGL viewer for geometry
  • React/TypeScript frontend
  • Backend services in Python/TypeScript

What to Build First (Minimum Wedge)

  1. PLM → Snapshot → View: Open from PLM, create immutable snapshot, run translation, load viewer fast with tessellated geometry
  2. DFM Check → Findings → Report: Run deterministic DFM analysis, display findings with pinned highlights on geometry, generate report from template
  3. Publish Back to PLM: Attach artifacts (report PDF + findings JSON + run log) back to the PLM item revision
  4. Collaboration Basics: Comments and tasks tied to snapshot + geometry anchors with owner/status/SLA
  5. Human-in-the-Loop: "Open in CAD" → engineer edits in native tool → connector agent detects change → resume workflow with cache-aware recomputation

Why This Is Fastest

  • Avoids forking a giant IDE codebase
  • Leverages web rendering for viewer and markup immediately
  • Keeps "native CAD editing" out of scope — relies on connectors
  • Most code is TypeScript/JavaScript + backend services — fewer C++ platform headaches
  • Smaller team can ship in 3–4 months

Where It Will Hurt Later

Pain point Detail
Viewer performance on large assemblies 500+ parts will hit WebGL ceilings
Geometry anchor stability "Good enough" across revisions but needs confidence-based remapping and reattach UX
Shell extension framework Will need reworking as the product expands to more skill types

Path B — Best Quality Product

Goal: Build a workstation-class engineering cockpit that scales to large assemblies, survives years of evolution, integrates deeply with CAD/PLM, and feels native and rock-solid.

Two variants exist — pick one consciously, as they have very different engineering costs.

Variant B1 — Full Native (Highest Performance, Hardest Engineering)

Stack: Qt/QML native UI, OpenGL/Vulkan rendering, C++/Rust core engine, stable plugin ABI

Why best quality: - Massive assemblies and complex markup stay responsive at 60fps - Full control over memory, threads, and GPU utilisation - Easier to certify for enterprise IT (predictable, measured install footprint) - No Chromium overhead — native performance ceiling dramatically higher

Why expensive: - Building a robust native 3D viewer with markup, sectioning, and measurement is substantial engineering work - Cross-platform packaging + GPU driver issues still exist, just differently - "CAD viewer vendor-level" engineering effort - Risk: burning years of engineering before validating product-market fit

Architecture:

Desktop Shell (Electron or Tauri)       — UI layer only
        ↓  gRPC / IPC
Local Core Service (Rust/C++)           — geometry index, anchor remapping,
                                          diff engine, large-model streaming,
                                          LOD generation, rules execution
        ↓  backend services
Translation + Heavy Compute             — local or server-side (enterprise)

Why this wins long-term: - Near-native performance where it matters (core geometry operations + viewer pipeline) - UI iteration stays fast (React/web tech, not C++ recompiles) - Avoids a deep IDE fork AND avoids writing an entire native UI framework from scratch - Can still ship a very "native-feeling" desktop product if the core is fast and the UI is disciplined - The Rust/C++ sidecar can be introduced incrementally — start with JavaScript/Python, migrate hot paths when performance demands it

Non-Negotiable Architectural Boundaries

These four decisions must be locked on day one, regardless of which path is chosen. They are the spine of the product. Getting them wrong is a rewrite; getting them right means every future addition — new agents, new viewers, new skill plugins — slots in cleanly.

1. The Snapshot / Run / Artifact Model

Every check, review, and report must be reproducible and versioned. This is the foundation for:

  • Collaboration — everyone sees the same immutable snapshot and the same run results
  • Audit — any finding can be traced back to specific geometry, rule, and tool version
  • AI context — the AI assistant (Dexter) can see all artifacts and their lineage
  • Caching — same inputs + same tool versions = same output hashes → re-runs are instant

2. The Connector Agent Boundary

Native CAD/CAE tools (CATIA, NX, SolidWorks, Creo, HyperMesh, ABAQUS) are external authorities. The platform never ships their binaries. Instead:

  • A Connector Agent runs on the engineer's workstation or VDI
  • It launches the correct native tool with the correct workspace context
  • It watches for output changes (local file watcher for fast iteration, PLM revision detection for governed workflow)
  • It validates and uploads updated outputs back to the platform
  • It collects screenshots, recordings, and GUI action logs for AI awareness

This keeps the tight, continuous loop without crossing licensing, VDI certification, or vendor contract boundaries.

3. Translation Pipeline as a Governed Service

Translation of native CAD formats is not a one-time import. It is a governed, versioned, compiler-like step:

  • Each translation artefact is versioned by translator vendor + version + profile
  • Treat translator updates like compiler upgrades: with automated regression tests against a benchmark dataset
  • Produce: B-Rep (for deterministic checks) + tessellation (for viewing) + PMI + assembly graph + diagnostics

4. Geometry Anchor Strategy

Comments, findings, and approvals anchor to specific geometry (faces, edges, features). These anchors can break when the model is revised — the topological naming problem.

Pragmatic strategy: 1. Use persistent IDs from the translator SDK when available (best stability) 2. Fall back to geometric signatures (centroid + area + normal hash) for matching across revisions 3. Assign a confidence score to each remap (high / medium / low) 4. Show a "reattach" UX with screenshots when confidence is low — engineer confirms or manually re-anchors

Accept that perfect anchor stability is impossible. Design the UX to handle graceful degradation.

Final Recommendation

Start with the fastest path shell (Electron/Tauri + WebGL viewer) BUT architect it like the hybrid best-quality variant: keep a clean separation between UI, core services, and backend so you can move heavy parts into a Rust/C++ core service when you hit scale or performance limits.

Decision rationale: - Validates product-market fit quickly (Path A speed) - Does not create a rewrite cliff when performance demands grow (Path B2 architecture) - The four non-negotiable boundaries ensure every future addition slots in cleanly