DesignSetGo apps
How it works Examples Docs Pricing Blog WP Blocks Install free

Blog /

Apps as content: the case for the Gutenberg block as the default embed surface

By Nealey

A long-running argument with myself, finally written down.

Most app runtimes for WordPress treat the standalone page as the headline surface. You build an app, you deploy it, it renders at /apps/your-thing/, you link to that URL from a button somewhere. The block embed (if it exists at all) is a nice secondary option for “if you want to put it inside a post.”

I think that has the priority exactly backwards.

The block embed is not the secondary surface. It is the primary one. The standalone page is the fallback for the cases where the block does not fit.

This post is the argument. It matters because if you are building DesignSetGo Apps and you treat /apps/{slug} as the default, you will keep losing the part of the audience the wedge is for.

How site owners actually think

I have watched maybe forty people install DesignSetGo and try to use it for the first time. The non-developers (persona P1 in our personas doc: site owners, food bloggers, real-estate agents, fitness coaches) all do the same thing.

They install the plugin. They look at the admin menu. They find the apps list. They see a row that says mortgage-calculator with a URL like /apps/mortgage-calculator/. They click it. They see the calculator at its own URL. They look mildly confused. They go back to the admin and ask the question I keep hearing:

“How do I put this in a listing?”

The standalone page is not what they want. They want the calculator inside the listing, the calculator inside the article, the calculator inside the product page. Their mental model is not “I have an app, it lives at a URL.” Their mental model is “I have posts and pages. Content goes in them.”

The standalone page is the architect’s surface. The block embed is the writer’s surface.

How developers think (and where the bias comes from)

Developers (persona P2, P3) default to standalone surfaces because they come from a world where apps have URLs. Vercel deploys to a URL. A React app routes to URLs. The CLI says “deployed to https://your-app.example.com” and you click it.

That mental model leaks into how we describe the product. “Build an app and deploy it to your WordPress site” sounds, to a developer, like “the app has a URL on the site.” Which is true, but it is also not the wedge.

The wedge is this:

The calculator on the real-estate listing is part of the listing. The quiz in the blog post is part of the blog post. The product configurator on the WooCommerce product page is part of the product page.

That is what the block embed makes possible. The standalone URL is fine. It is not why anyone bought.

Why blocks beat pages on the durability axis

There is also a more boring reason to lead with the block: it is what survives.

If you put your calculator at /apps/mortgage-calculator/ and link to it from your sidebar, that link rots. Your sidebar gets redesigned. The theme changes. The page slug moves. The standalone URL has no native audience; you have to drive traffic to it.

If you put the same calculator inside every relevant listing as a block, it is part of the content. It is in the post body, in the database, in the editor’s UI, in the version history. Six months from now when you change themes, the block is still in the post. When you reorganize the menu, the block does not care. When you do a site search for “mortgage” to remind yourself which posts have the calculator, the search engine sees it because the block renders inline as part of the post body.

The block embed makes the app part of the content lifecycle. The standalone page makes the app a separate object the content has to point to.

The three display modes, properly ranked

DesignSetGo Apps supports three display modes in the manifest:

"display": { "modes": ["block", "page", "admin"], "default": "block" }

Lead with "block". Use "page" when the app legitimately needs its own URL (a multi-page member portal, a dashboard, a customer login surface, anything that is the destination rather than a section of a destination). Use "admin" when the app is a tool for the site owner, not the site visitor.

The defaults in the starter template now ship with block first. We caught ourselves shipping page first earlier this year and changed it. The order in the array is also the order shown in the install dialog, and we noticed P1 testers reading “page” first and thinking that was the recommended choice.

When the standalone page is right

This is the part I do not want to undersell. Some apps should live at their own URL.

  • Multi-page portals. A member dashboard with /apps/portal/billing, /apps/portal/profile, /apps/portal/orders is a real app and wants its own URL space. Yesterday’s agency client dashboard tutorial is exactly this case.
  • Long-running customer surfaces. A product configurator with deep linking, sharable URLs, and back-button support is a page.
  • Admin tools meant for one persona. An internal team dashboard is display.modes: ["admin"], not ["block"].
  • Apps that are the whole experience. A multi-page quiz, a course catalog browser, an interactive documentation site.

In each case, ask “is this the page, or is this a section of a page?” If it is the page, ship page mode. If it is a section, ship block mode.

The pricing page on designsetgo.dev itself (post 27 in the calendar) is the most interesting case: it is both. The page surface is the user-facing pricing page. The block surface is the embedded plan picker that lives inside other posts (“here is what Plus includes” embedded inside a feature breakdown post). One bundle. Two surfaces. The bundle was always going to be block-first.

How this lands in the product

A few decisions we have made that follow from this:

The block insertor is the install dialog’s natural next step. After install, the next-step copy is “Open a post to embed this app,” not “Visit the URL.” We changed this in the install confirmation page two weeks ago and the cohort that follows the next-step CTA went up about 30 percent.

The Gutenberg block’s name uses the app’s display name. Not a generic “DesignSetGo App” placeholder. If your app is “Mortgage Calculator,” that is what shows in the block picker. Discoverability inside the editor is the path the writer takes.

The block previews render the actual app, not a placeholder. In the editor, the writer sees the calculator (or a loading state if the bridge needs real data). They are not picking from a list of named black boxes.

/apps/{slug} is the developer’s URL. It is what shows up in the CLI output, in the deploy log, in the troubleshooting docs. The writer never has to know it exists. The developer never has to live without it.

The shorter version

The block embed is the wedge. The standalone page is the fallback. If you are building a DesignSetGo App today, ship display.modes: ["block", ...] first and ask whether you also need a page later.

The mental model: apps as content. Not apps as destinations.

Further reading

Keep reading

More from the blog.