Architecture and alternatives

The version of Etch Studio that would have kept everyone: one app, three backends

Last reviewed:

Analysis

Full breakdown

This page is analysis. It argues from architecture rather than quotation. Every other article on this site is primarily a dated record; this one is a counterfactual. Saying so upfront protects the credibility of the pages that are pure record.

What the two products share

Does not look any different from Etch.

In EtchWP, you had a loop manager and you configured loops in PHP because … that's how WordPress demands that it be done.

PHP authoring was a backend constraint. The canvas above it was always Svelte. Splitting into two products with two checkouts treats an adapter problem as a product boundary.

What an adapter layer is

An adapter translates between the Svelte canvas and a persistence backend:

BackendServes
WordPress (headless or classic)Agencies and clients who need WP, WooCommerce, existing plugins
SQLiteSmall sites, local dev, simple deployments
PostgresScale, relational data, multi-tenant SaaS patterns

Output is a separate choice: vendor-hosted, self-hosted, or static deploy to Cloudflare. Same engine, user's choice at each layer.

One multi-tenant Svelte canvas with adapter-based backendsONE multi-tenant Svelte canvas — EtchWP and Studio share thisData adapter (user's choice)WordPress (headless or classic)SQLite file (small / local / simple)Postgres (scale / relational)Output / ops (user's choice)Fully hosted by vendorSelf-hosted by youStatic deploy (Cloudflare)Same engine. Same customers. One license. No second checkout.
The architecture EtchWP and Etch Studio share — one canvas, adapter-based backends.

Their own concessions

On August 25, 2026, Geary described:

  • Studio-to-WordPress and WordPress-to-Studio conversion as a stated goal
  • A unified dashboard where Studio and WordPress projects appear together
  • Porting Studio architecture to WordPress the same way the asset manager was ported

Those are one-product statements. The product split contradicts them.

The honest difficulties

This counterfactual is not free:

  1. Adapters are real engineering. WordPress headless, SQLite, and Postgres each need a persistence layer with different query models, loop semantics, and deployment paths.
  2. Relational features are harder on WordPress. Geary said Studio is a true relational database and relationships are easier there. That is true. It is an argument for better adapters, not for a second checkout.
  3. Hosting has real cost. A hosting fee is justified. A separate product entitlement for the same canvas is a different question.

What it would have preserved

What happenedOne-app version
Who paysNew Studio subscriptionPeople who already paid
New featuresStudio first, port laterShip once, map to adapters
Self-host"Possible, don't know yet"User choice
DataVendor database or WordPress blocksAdapter: WP · SQLite · Postgres

Existing lifetime and annual customers funded the canvas. They did not fund a hosted-only second product.

The reader-facing shape: one Etch app endpoint where LTD holders see all their sites — WordPress and hosted — listed together, with hosted or self-hosted output as a user choice. On August 25, 2026, Geary described that shape as a goal:

Think about a unified dashboard where your studio projects and your WordPress projects show up all at once … that would be phenomenal.

If that ships, LTD backers should not pay a monthly fee to enter it, and a self-hosted non-WordPress option should exist. For why hosting is the billable layer and the canvas is not, see How much does Etch Studio cost?.

See EtchWP vs Etch Studio for the product comparison and Can you self-host Etch Studio? for why hosted-only was chosen.

Quick answers

Frequently asked questions

Is this what Digital Gravy should have built?
This page is analysis, not a vendor statement. The argument is architectural: the same Svelte canvas already exists in both products, and the split is persistence and entitlement, not interface capability. A single application with adapter-based backends is standard practice in the industry. The vendor's own stream comments point toward unified dashboards and cross-product conversion as stated goals.
Would one app have been easy to build?
No. Adapters are real engineering. Relational features are genuinely harder on WordPress than on a native relational database. Hosting has real cost that justifies fees — but fees for hosting, not a second product entitlement. This page includes the difficulties honestly because pretending otherwise would weaken every quotation-based page on the site.
Does the vendor agree this is possible?
Partially, in their own words. On August 25, 2026, Geary described Studio-to-WordPress conversion and a unified dashboard as stated goals. He said PHP loop configuration was a WordPress constraint, not a product identity. Those concessions point toward one product with two persistence modes rather than two products with separate checkouts.
What would it have preserved?
Lifetime and annual EtchWP customers would have kept access to the canvas they funded. New architecture would ship once and map to adapters rather than landing in a product their license excludes. Self-host and hosted output could coexist as user choices. The people who paid for Era 4 would not face a second subscription for the same interface.

Evidence

Sources used

YouTube streams

  • WDD LIVE 128 (Aug 25, 2026)2026-08-25

Blog and marketing pages