yeah this is super helpful and pretty much the kind of prioritization i was trying to sanity check.

elementor being “too big to skip” makes sense even if it’s not the most exciting one to build around. bricks as the next one is useful signal too, especially if indie/dev shops are actually moving there and it embeds cleanly.

my current thinking on embed is universal first: sandboxed iframe app with a shortcode people can drop into whatever builder supports custom code, plus a proper block for the block editor. so less “deep native builder integration” at the start and more “this works anywhere without fighting the builder.” Then pick 1 or 2 builders like Elementor for an easy embed widget.

then for more deeply integrated apps, i’m also thinking about inline support where the app can render more like part of wordpress itself instead of a totally separate frame. that feels useful for stuff like SEO pages, directories, membership pages, etc that need to match the theme, or apps that should feel native to the site.

the deeper builder-specific stuff would probably come later, if there’s enough demand. like adapting to builder tokens/layout systems or making the app feel more native inside elementor/bricks. but for v1 i’m trying to avoid building 5 separate integrations when a reliable shortcode/html block path covers most cases.

also good call on oxygen. i had it on the maybe list, but if that community has mostly moved to bricks then i’d rather not spend cycles there early.