Build vs buy: should you build a visual editor or license one?

The decision, stated honestly

The build-versus-buy question is almost never about whether you can build an editor. You can. Our own benchmark shows a working editor in 14 lines of code. The question is what happens in the eleven months after that demo.

Here is the honest shape of it: the engine is 8% of the work. The other 92% is everything a customer expects around the engine and no open-source project will give you — an interface that does not look like a developer tool, a block library that matches your product, somewhere to put uploaded images, autosave that does not lose work, permissions so one tenant cannot open another tenant's page, and a QA pass across browsers and assistive technology.

Run the numbers for your situation

The defaults are our estimates, and you should change them. If you already have an asset service, uncheck that line. If your design system gives you the block components, cut that estimate in half. The calculator does not care which answer it produces, and at low licence prices with a small block set it will tell you to build.

Where the 520 hours come from

Engine integration — 40 h. Mounting the editor, wiring configuration, dynamic import for SSR, basic event plumbing. This is the part that feels fast, because it is.

Replacing the editor UI — 120 h. Every open-source engine ships a functional but plain interface. Look at the screenshots in our benchmark: that is what your customers would see. Restyling panels, building a settings sidebar that matches your product, and making the whole thing responsive is a genuine front-end project.

Block library — 100 h. A page builder with generic text and image blocks is not useful. Your customers need blocks that reflect your product — pricing tables, testimonial sections, booking widgets — each with its own settings, defaults, responsive behaviour and preview.

Asset management — 80 h. Upload, storage, thumbnails, a picker, deletion, and quota. Everyone underestimates this because it sounds solved. It is solved, in services you still have to integrate.

Persistence and versioning — 60 h. Autosave, conflict handling, draft versus published state, and a way to recover the previous version when a customer breaks their page at 2am.

Permissions — 60 h. Multi-tenant isolation, sharing, roles. Security-critical, so this is the work you cannot rush.

QA and accessibility — 60 h. Cross-browser behaviour of drag-and-drop is genuinely difficult, and keyboard accessibility in a drag-and-drop editor is harder than most teams expect.

When building is the right answer

The editor is your product's differentiator. If customers choose you because of the editing experience, outsourcing it to a vendor whose roadmap you do not control is a strategic error, not a cost saving.

Data residency or procurement rules out hosted vendors. If page content cannot leave your infrastructure, most commercial SDKs are out before price enters the conversation. Self-hosted options exist — PageKit and the self-hosted category page list them — but the shortlist gets short quickly.

Per-customer pricing works against you. Several SDKs price per end-user account or per email sent. At ten thousand low-activity accounts, a fixed engineering cost can beat a metered one badly. Model it with your own customer count before signing.

You need capabilities no vendor sells. Deep integration with your data model, an unusual output format, or editing surfaces that are not pages at all.

When buying is the right answer

Email. Do not build an email editor. The hard part is not the drag-and-drop, it is that Outlook renders HTML with the Word engine and every mail client is different. Vendors maintain rendering test labs for exactly this reason. See the email template builder use case for the options.

You need it this quarter. 520 hours is roughly one engineer for three months, and that engineer is not building your product while they do it.

The editor is a checkbox, not a differentiator. If customers tolerate the feature rather than choose you for it, spend the smallest amount that clears the bar.

The middle path most teams miss

There is a third option that the framing hides: build on an open-source engine and buy the parts around it. GrapesJS is the clearest example — the engine is free, and the surrounding application is available commercially from the same team as the Studio SDK, so you are not choosing between a blank page and a walled garden.

Whichever way the calculator points for you, run it with your own numbers before the meeting rather than during it. The full comparison table has the licence prices to plug in, and the methodology page explains where each of those prices came from.