I’ve been building with the Vibe Coding Block for a while now, and at some point it hit me: this thing is a full front-end. Tailwind, shadcn/ui, any npm package, real query builders against live data, CRUD with permissions. I can build literally any design I want. No template, no block library, no compromise.
So the obvious thought: why is this only for the members area?
Imagine a client’s entire public website running on Softr. Completely bespoke design, built in the Vibe Coding Block. And the CMS behind it is just… Softr. Airtable or Softr Databases as the source, the client edits a record, the site updates. No Webflow, no Squarespace, no WordPress, no second tool, no second invoice. One platform for the marketing site AND the portal behind the login,
sharing the same data.
That would be massive. And honestly? We’re maybe four features away.
The wall: everything renders in the browser
Right now the Vibe Coding Block is documented as browser-only — no server-side code. Which is completely fine for a dashboard behind a login. But for a public page it means:
- The raw HTML contains no content. Google renders JavaScript eventually, but social scrapers (WhatsApp, LinkedIn, Facebook, Slack) never do. Every link anyone shares shows the default preview, not the article.
- Detail pages only exist as
?recordId=rec.... Query-parameter URLs get
treated as second-class by search engines. - Those record pages never make it into
sitemap.xml, so the only path to them
is the rendering itself.
And here’s the frustrating part: Softr already solved all of this. The native List + Item Details blocks have SEO:Slug, SEO:Title, SEO:Description, clean path URLs, per-record sitemap entries. The whole pipeline exists and works. Vibe blocks are just cut off from it.
Custom Code blocks don’t bridge the gap either — they give you raw HTML but no record context. So you can have server-rendered markup OR live record data, never both.
What it would take
1. A head API for the block. Let the block export a second function that Softr runs server-side, before the HTML goes out:
export async function getMeta({ record, params }) {
return { title, description, image, canonical, jsonLd }
}
This is the big one, and it’s far smaller than full SSR. It fixes social previews, search snippets and structured data in one move. We already write exactly this logic today — it just runs too late, in the browser, after the scraper has already left.
2. Path-based routing. Let a Vibe page declare a route like /blog/:slug and receive params server-side, instead of only ?recordId=.
3. Sitemap participation. Let a Vibe block declare its datasource and slug field so Softr can list those record URLs in sitemap.xml — the same way it already does for native blocks.
4. Real HTTP status codes. An unknown slug should return 404, not 200 with an empty state. Otherwise search engines collect soft 404s.
5. (Stretch goal) Server-render or pre-compile the block. Today the block code ships as source and gets compiled in the browser, which costs LCP and INP on top of everything else. Compiling at publish time with hydration would fix content and Core Web Vitals in one shot.
Items 1–4 are enough. Item 5 is the dream.
Bonus, but it blocks testing
Every *.softr.app subdomain serves User-agent: * / Disallow: /, no matter what you set in App Settings. That’s sensible as a default, but it means you cannot verify any of this until a custom domain is attached. An indexable staging mode — even opt-in, even behind a warning — would make this testable.
Why this matters commercially
Right now I tell clients: “Softr for the portal, keep Webflow for the website.” Two platforms, two subscriptions, two places to maintain, and content that never quite lines up.
With the four items above, that sentence becomes: “Softr for everything.” Marketing site and portal sharing one database, one design system, one bill. For agencies that’s not a nice-to-have, it’s the difference between Softr being a tool in the stack and Softr being the stack.
The Vibe Coding Block already made Softr a serious front-end. This is what would make it a serious website platform.
Anyone else running into this? Would love to know if I’m alone here or if this is a common wall.