Coverage reports
Route coverage should make explicit what is mapped, what is inferred, and what still falls back to preservation-heavy output.
Docs
Documentation and route coverage
Supported inputs, target expectations, known limitations, and route status should be discoverable before someone trusts the engine with a real migration.
Known limitations
Custom JavaScript, plugin-specific parity, proprietary widgets, and motion systems all need honest documentation instead of vague promises.
Access model
Current front-end surfaces
- Hosted website workspace
- WordPress connector plugin
- ChatGPT connector
- Claude connector
Protection model
What stays private
The proprietary conversion engine should remain server-side. Plugins and connectors should act as clients that send jobs into the protected system rather than carrying the engine code locally.
Access paths
Every access path should feel like the same product.
Universal By Foundation should expose the same protected engine through different entry points, with each path optimized for a different kind of production workflow.
Hosted workspace
The hosted workspace is the baseline access path. It is the fastest way to test a route, inspect warnings, review preserved output, and build confidence before rollout.
WordPress connector
The WordPress connector should behave like a thin client. It authenticates the site, packages the source, sends jobs to Universal By Foundation, and returns results without embedding engine logic locally.
ChatGPT connector
The ChatGPT path is best framed as an assisted client surface, not a replacement engine. It should help users submit work into the protected backend and receive structured output safely.
Claude connector
The Claude path should follow the same contract as ChatGPT: advisory entry point, protected backend execution, and no engine code exposure in the client-facing layer.
Current route docs
| Route | Status | Known limitations |
|---|---|---|
| Elementor → Divi | Stable | Plugin-specific widgets may fall back to preserved structures • Custom JavaScript is preserved, not recreated as native motion |
| Elementor → Divi 4 Legacy | Stable | Widget parity depends on route coverage and deterministic mappings. • Preserved structures should still be reviewed before import. |
| Elementor → Elementor | Stable | Addon-heavy pages may still need review warnings • Dynamic theme metadata is preserved structurally, not always rehydrated natively |
| Elementor → HTML / Code | Stable | Widget parity depends on route coverage and deterministic mappings. • Preserved structures should still be reviewed before import. |
| Divi → Elementor | Stable | Advanced addon modules still rely on deterministic coverage or preserved fallback • Theme-level behavior remains outside strict 1:1 parity |
| Divi → HTML / Code | Stable | Widget parity depends on route coverage and deterministic mappings. • Preserved structures should still be reviewed before import. |
| Divi 4 Legacy → Elementor | Stable | Bespoke shortcode wrappers may preserve structure rather than become native widgets • Addon-heavy legacy pages still need manual review before import |
| Divi 4 Legacy → HTML / Code | Stable | Widget parity depends on route coverage and deterministic mappings. • Preserved structures should still be reviewed before import. |
| Code → Elementor | Stable | Complex app-shell behavior is preserved rather than rebuilt as native widgets • Pixel-perfect script-driven UI remains out of scope |
| Code → Divi | Stable | Custom interactions are preserved rather than rebuilt as native behavior • Highly bespoke markup may land as code modules or preserved blocks |
| Code → Divi 4 Legacy | Stable | Widget parity depends on route coverage and deterministic mappings. • Preserved structures should still be reviewed before import. |
| Figma → Divi | Beta | Full binary-canvas parity is not yet live • Component mapping remains beta and review-heavy |
| Figma → Elementor | Beta | Component resolution remains beta • Do not treat this as a pixel-perfect design-to-builder promise |
| Figma → HTML / Code | Beta | Widget parity depends on route coverage and deterministic mappings. • Preserved structures should still be reviewed before import. |
| Webflow → Divi | Beta | Interaction semantics remain beta • Component fidelity and production-ready parity are not yet guaranteed |
| Webflow → Elementor | Beta | Interactions, variants, and component fidelity remain beta • Use as a structure-aware starting point, not a 1:1 migration promise |
| Webflow → HTML / Code | Beta | Widget parity depends on route coverage and deterministic mappings. • Preserved structures should still be reviewed before import. |
| Wix → Divi | Experimental | Widget parity depends on route coverage and deterministic mappings. • Preserved structures should still be reviewed before import. |
| Wix → Elementor | Experimental | Widget parity depends on route coverage and deterministic mappings. • Preserved structures should still be reviewed before import. |
| Wix → HTML / Code | Experimental | Widget parity depends on route coverage and deterministic mappings. • Preserved structures should still be reviewed before import. |
Elementor → Divi
Move Elementor layouts into Divi output
Strong on layout, core widgets, loops, menus, pricing, sliders, tabs, and accordions.
- Addon-heavy pages should still be reviewed before import
- Dynamic templates may preserve structure rather than produce strict native parity
Elementor → Divi 4 Legacy
Use Elementor to Divi 4 Legacy conversion
Route coverage follows the engine-supported path for this source and target.
- Review fallback-heavy sections before import.
- Treat preserved blocks as explicit fidelity warnings, not hidden failure.
Elementor → Elementor
Clean and re-emit Elementor structures through the universal layer
Strong on same-builder structural validation, preserved shortcode handling, and route audit work.
- Treat this route as cleanup and audit, not blind normalization
- Widget parity improves as deterministic coverage expands
Elementor → HTML / Code
Use Elementor to HTML / Code conversion
Route coverage follows the engine-supported path for this source and target.
- Review fallback-heavy sections before import.
- Treat preserved blocks as explicit fidelity warnings, not hidden failure.
Divi → Elementor
Move Divi layouts into Elementor output
Strong on Divi 5 and Divi legacy structural routes, with growing support for addon-heavy modules.
- Custom Divi child-theme modules still need route review
- Highly bespoke shortcode wrappers may preserve rather than map natively
Divi → HTML / Code
Use Divi to HTML / Code conversion
Route coverage follows the engine-supported path for this source and target.
- Review fallback-heavy sections before import.
- Treat preserved blocks as explicit fidelity warnings, not hidden failure.
Divi 4 Legacy → Elementor
Move Divi 4 legacy layouts into Elementor output
Stable on legacy shortcode parsing and structural output, with higher review expectations on bespoke or addon-heavy legacy modules.
- Expect more review on highly customized legacy builds
- Treat preserved blocks as honest fallback, not failed output
Divi 4 Legacy → HTML / Code
Use Divi 4 Legacy to HTML / Code conversion
Route coverage follows the engine-supported path for this source and target.
- Review fallback-heavy sections before import.
- Treat preserved blocks as explicit fidelity warnings, not hidden failure.
Code → Elementor
Translate code and templates into Elementor-ready output
Strong on structural HTML/CSS and preserved code blocks, with safe handling for PHP templates and JSX-oriented sources.
- Custom JS is preserved safely, not executed
- Behavior-heavy sections should be reviewed in preview before import
Code → Divi
Turn code-based layouts into Divi-compatible output
Strong on structural conversion and preserved code modules, with route-aware validation before export.
- Treat this as structured portability, not visual cloning
- Review code-module-heavy outputs before handoff
Code → Divi 4 Legacy
Use Code to Divi 4 Legacy conversion
Route coverage follows the engine-supported path for this source and target.
- Review fallback-heavy sections before import.
- Treat preserved blocks as explicit fidelity warnings, not hidden failure.
Figma → Divi
Translate structural Figma data into Divi-oriented output
Beta on archive-safe ingestion and shell semantics. Not yet a production-safe claim for broad design fidelity or component parity.
- Use this as an experimental route, not a production parity promise
- Keep route messaging centered on structure-aware extraction
Figma → Elementor
Translate structural Figma data into Elementor-oriented output
Beta on archive-safe ingestion, shell semantics, and layout normalization. Not yet production-safe for broad design fidelity claims.
- Best used for experimentation and internal validation
- Keep production messaging narrow until broader semantic coverage is proven
Figma → HTML / Code
Use Figma to HTML / Code conversion
Route coverage follows the engine-supported path for this source and target.
- Review fallback-heavy sections before import.
- Treat preserved blocks as explicit fidelity warnings, not hidden failure.
Webflow → Divi
Bring Webflow structure into Divi-oriented output
Beta on structure, shell semantics, and experimental builder output. Not yet a production-safe claim for Webflow interaction parity.
- Treat this as experimental route discovery rather than final migration output
- Keep production claims narrow until broader semantic coverage is locked
Webflow → Elementor
Bring Webflow structure into Elementor-oriented output
Beta on structure, grid semantics, and shell-level output. Not yet a production-safe parity claim for Webflow interactions or component fidelity.
- Keep this route framed as beta-only until broader parity is proven
- Best used for internal validation, experiments, and early route discovery
Webflow → HTML / Code
Use Webflow to HTML / Code conversion
Route coverage follows the engine-supported path for this source and target.
- Review fallback-heavy sections before import.
- Treat preserved blocks as explicit fidelity warnings, not hidden failure.
Wix → Divi
Use Wix to Divi conversion
Route coverage follows the engine-supported path for this source and target.
- Review fallback-heavy sections before import.
- Treat preserved blocks as explicit fidelity warnings, not hidden failure.
Wix → Elementor
Use Wix to Elementor conversion
Route coverage follows the engine-supported path for this source and target.
- Review fallback-heavy sections before import.
- Treat preserved blocks as explicit fidelity warnings, not hidden failure.
Wix → HTML / Code
Use Wix to HTML / Code conversion
Route coverage follows the engine-supported path for this source and target.
- Review fallback-heavy sections before import.
- Treat preserved blocks as explicit fidelity warnings, not hidden failure.
Plan notes
How access and plans should line up
- Free should stay restricted to a small route set, capped tokens, and no connectors or plugin access at launch.
- Lite should unlock the full route set with daily-reset token limits for individuals.
- Pro should serve developers and designers with larger token pools, better throughput, and deeper history.
- Agency should add team seats, larger token allocations, and rollout support.
Plan availability
Connector access should follow the plan shell.
Free
25 starter tokens each month
Hosted website workspace
Lite
40 tokens reset every day
Hosted website workspace, WordPress plugin connector, ChatGPT connector, and Claude connector
Pro
1,500 tokens each month
Hosted website workspace, WordPress plugin connector, ChatGPT connector, and Claude connector
Agency
8,000 shared tokens each month
Hosted website workspace, WordPress plugin connector, ChatGPT connector, Claude connector, and Team seats
Free remains the proof layer. Lite, Pro, and Agency are the plans where the hosted workspace, WordPress connector, ChatGPT, and Claude can line up as real access paths.
Staged expansion
Expansion should be visible, but clearly staged.
- Gemini should be treated as staged connector expansion, not baseline commercial scope.
- Figma, Webflow, Framer, and future ecosystem connectors should appear as roadmap-level additions until route quality and operational controls are ready.
- Docs should separate “available now” from “planned next” so buyers do not confuse experiments with production guarantees.
The first production-minded commercial story for Universal By Foundation should stay centered on the hosted workspace, WordPress connector, ChatGPT, and Claude.