BuilderJS

A White-Label Builder for Agency Client Portals

If you run an agency, you've felt the squeeze: every client portal needs an editor, and most embeddable builders charge per seat or per workspace — so the bill grows with every account you onboard. BuilderJS flips that. It's a framework-agnostic, vanilla-JS drag-drop builder library (~140KB) that mounts inside any DOM node in your existing React, Vue, Angular, Svelte, Next.js, or Laravel app. You buy it once on CodeCanyon, own the source, and self-host. It builds both Outlook-safe HTML email and full web/landing pages from the same JSON-first editor. It's white-label out of the box — your logo, your CSS, your locale — and multi-tenant capable: the builder is closure-captured per mount, so YOUR app keeps owning tenant isolation, seats, and billing. One important boundary: BuilderJS is the editor your clients use to build templates and markup. You bring the hosting, the ESP, and the sending.

One license, every client tenant

Most embeddable builders meter you on the axis agencies grow fastest — accounts. As of June 2026, Unlayer's white-label tiers run Launch at $250/mo, Scale at $750/mo, and Optimize at $2,000/mo (source: unlayer.com/pricing). A hosted website tool like Webflow stacks an Agency Workspace at roughly $35/seat/mo (billed annually) on top of a per-published-site fee — Basic sites at $15/mo and Premium sites at $25/mo on annual billing — so every client site you ship adds recurring cost (source: webflow.com/pricing and the Webflow Help Center May 2026 pricing update, as of June 2026). BuilderJS has a different shape entirely: a one-time CodeCanyon purchase (item 27146783, Regular $52 / Extended $99), no monthly fee, no per-seat charge, no usage metering, and no phone-home. You mount the same bundle into tenant #1 and tenant #1,000 with zero incremental license cost. Onboard a hundred clients this quarter and the license line on your P&L does not move.

White-label down to the pixel — because you own the source

White-label isn't a checkbox tier here; it's the default consequence of owning the code. You get dist/builder.js + dist/builder.css and the reference backends, so you control the chrome, the color tokens, the element palette, and the copy. The builder ships with i18n across 20+ locales including RTL, so a client portal in Arabic or Hebrew renders correctly. Need a custom block — a client's pricing-card pattern, a booking widget, a branded footer? Extend without forking via Builder.registerElement to add Elements, Widgets, and Controls, plus your own themes. Across the surface there are 42 element types, 59 controls, and 31 overlays to build on. Nothing in the rendered UI says BuilderJS unless you want it to. The only BuilderJS-branded thing your clients ever touch is the editor you've already re-skinned as your own product.

Multi-tenant capable — your app owns isolation

Let's be precise about the boundary, because agencies live and die on data separation. BuilderJS is multi-tenant CAPABLE: each editor instance is closure-captured at mount, so you can spin up an isolated builder per tenant in the same app shell. But BuilderJS does not implement tenancy for you — YOUR application owns isolation, seats, roles, and billing. The data contract is deliberately simple: getData() returns a lossless JSON document, load() restores it from that JSON, and you POST that JSON to your own route scoped to the tenant. The reference PHP backends (MySQL/SQLite/S3 for save, upload, and auth) are starter code you copy and own; port them to Node, Go, or Python and wire your existing tenant guard in front. The builder never sees your customer database. It hands you JSON; your stack decides who can read and write it.

Email AND pages from one embed

Agencies rarely need only one output. BuilderJS produces both from the same editor. For web work it emits clean page HTML. For email it runs the EmailExportPipeline: flexbox collapses to tables, SVGs rasterize to PNG, @media rules stack the layout on mobile, MSO conditionals wrap Outlook quirks, and a CSS inliner finishes the job — so the markup survives real inboxes. There are 30+ templates and 200+ samples, Litmus-tested across 22 clients, to start your clients from. To be clear about the verb: BuilderJS builds the email template and the page markup. It does not send the email or host the page — you hand the exported HTML to your client's ESP for sending and to your own infrastructure for hosting. One editor, two outputs, and your delivery stack stays exactly where it is.

Mounts inside the stack you already ship

BuilderJS is a DOM-mount bundle, not a published npm React or Vue component — which is what makes it framework-agnostic. You mount it client-side into a node you control: in React from useEffect, in Vue from onMounted, in Angular from ngAfterViewInit, in Svelte from onMount. In Next.js, dynamic-import it with ssr:false inside a 'use client' component so it never runs on the server. Persist with getData() → POST to your route. That's the whole integration: a div, a mount call, and a save handler. It drops into a Laravel admin, a Next.js client dashboard, or a plain-HTML portal with the same two files. Pluggable, vendor-neutral AI hooks are available if you want to wire in your own model — nothing is hard-coded to a vendor. Try the live editor at builder.emotsy.com before you build anything.

Frequently asked questions

Explore