Your engineer demos the new editing feature on Friday. Drag an element, draw a box, apply one filter. It works, the sprint looks done, and everyone moves on. Here is what that demo really represents. It is roughly 10% of the surface area, and the other 90% stays quiet until QA, mobile testing, and an accessibility audit bring it into view, usually around month three.
If you are adding image or video editing to a SaaS product or an agentic workflow, you are not really choosing whether the canvas works on Friday. You are choosing who owns that hidden 90% for the next several years. You can own it yourself by building the editor in-house, or you can adopt an off-the-shelf editing layer and own less of it. Full disclosure: Layermetry is one of those off-the-shelf layers, so we will lay out both paths and let you decide.
LEAN TOWARD BUILDING WHEN
- The editor is the core differentiating IP of your product, not a feature inside it
- Your rendering needs are extreme, like a custom WebGL or shader pipeline no off-the-shelf editor can meet
- Licensing cost at your MAU (Monthly Active User) or seat scale genuinely exceeds in-house total cost of ownership (TCO)
- Legal or security constraints forbid third-party runtime code in your environment
LEAN TOWARD ADOPTING WHEN
- The editor is a feature inside a larger product, not the product itself
- You need WCAG (Web Content Accessibility Guidelines) compliance, mobile touch, and cross-device pointer support on day one
- You want an agent-control surface without building a structured API from scratch
- You need to ship this sprint, not this quarter
Neither column is the wrong answer. The rest of this post is the math that tells you which one is yours.
The demo is a week. The iceberg is the rest
The drag-and-draw prototype takes a week because dragging, drawing, and applying one CSS filter are genuinely simple browser tasks. That part is real, and it is why the demo feels finished.
What the demo never shows is six separate engineering problems
What the prototype hides is the undo and redo stack, selection state across overlapping objects, SVG and raster interop when a user pastes a vector into a raster canvas, accessibility for keyboard and screen-reader users, cross-device pointer events for mouse, touch, and stylus, and a structured surface for an agent to call programmatically. Each of those is its own engineering problem with its own edge cases. None of them are visible until the first real user finds them, which is exactly why they slip past the Friday demo and surface in month three.
WHERE YOUR EDITOR BUILD BUDGET ACTUALLY GOES
The demo is the tip. The budget is below the waterline.
Both paths exist to handle that hidden 90%
There are two honest ways to handle those six layers. You build them yourself and keep total control over every line, or you adopt an off-the-shelf editing layer that ships them already built and keep your team focused elsewhere. The off-the-shelf editor category, which includes browser editor SDKs and embeddable client-side editors, exists precisely because that hidden work is large enough to be a product in its own right. The rest of this post walks the math so you can see which path your team is actually choosing.
What the build actually costs, in salary and months
A single engineer is more expensive than the salary line suggests
The US median annual wage for software developers was $133,080 in May 2024, per the BLS Occupational Outlook Handbook (BLS, May 2024). A single mid-level US engineer fully loaded runs roughly $166,000 to $186,000 per year after applying the 1.25x to 1.4x multiplier that covers payroll taxes, benefits, hardware, and recruiting overhead (industry fully-loaded-cost guides, directional). Senior engineers and engineering managers run higher, at $175,000 and $200,000 in US base salary for back-end and EM roles respectively (a large annual developer survey, 2025), which pushes fully-loaded costs to roughly $219,000 to $280,000 annually.
Plan for a floor of six to eight months, then add the edge cases
Vendor estimates from the off-the-shelf editor category, which have a direct interest in the number, put 6 to 8 months of senior developer time on the path to feature parity with a commercial editor built over a common open-source canvas library. Take that as a floor, not a budget. The real surface, once accessibility, pointer events, and undo-history edge cases are in scope, extends the timeline.
A widely cited 2018 developer survey found that around 42% of developer work time goes to technical debt and maintenance, and the hidden layers below the demo waterline are exactly where new tech debt accumulates. When you run the full build-or-adopt math at scale, the cost spread between a custom build and an adopted editor widens, and that breakdown is worth reviewing at volume.
The honest side-by-side
This is the table to actually argue over in a roadmap meeting. It is not built to make one column win. It is built so you can see where your effort goes on each path.
| Build from scratch | Adopt an off-the-shelf editor | |
|---|---|---|
| Effort | Your engineers own all six layers and every edge case | Integration plus configuration, with the layers shipped built |
| Initial cost | 1 senior dev x 6-8 mo = ~$110kâ$190k loaded | Per-seat or per-month license, and some open-source options are free |
| Time to ship | A quarter or more before the hidden layers are solid | This sprint, in most cases |
| Maintainability | 15â25% of build cost annually, indefinitely (directional) | License renewal, with the vendor carrying the upkeep |
| Control | Total: every line, every behavior, every pixel is yours | Bounded by the editor's surface and configuration |
| Dependency | None on a third party, so the risk stays internal | A live dependency on a vendor and its roadmap |
Prices and figures as of June 2026. Verify at source before budgeting.
The cost the table cannot show is opportunity cost
The columns above compare the visible numbers. The less visible one is opportunity cost. The senior engineer building undo-history edge cases in month four is not shipping the product features that actually differentiate you. That is the real trade behind the dependency column. Building keeps total control, and the price of total control is the roadmap time you spend owning plumbing instead of your edge.
Accessibility and pointer events are where canvas builds get quietly expensive
The canvas element gives you no accessibility scaffolding at all
The <canvas> element has no corresponding ARIA (Accessible Rich Internet Applications) role and does not expose its content to accessibility tools. The MDN Web Docs canvas reference puts it plainly: "In general, you should avoid using canvas in an accessible website or app." Every keyboard interaction, every focus indicator, every screen-reader label has to be implemented manually in JavaScript. There is no scaffolding. The engineer who shipped the Friday demo is now three months in, building keyboard focus management and screen-reader labels instead of product features.
Accessibility is a legal floor, not a nice-to-have
WCAG 2.2 (W3C Recommendation, published December 12, 2024) requires all functionality to be keyboard-operable at Level A (criterion 2.1.1), prohibits keyboard traps (2.1.2), and mandates visible focus indicators (2.4.7 AA). These are not optional for any product that serves the public. The scale of the work shows up in the WebAIM Million 2025 report. As of February 2025, 94.8% of the top one million homepages had detectable WCAG 2 failures, averaging 51 errors per page. Accessibility is routinely deferred and then more involved to retrofit later.
Pointer events are a second hidden build inside the first
Cross-device pointer events add a second layer of complexity. A production canvas editor must handle three distinct input types, which are mouse, touch, and pen or stylus, each with its own button-state logic. Pointer capture is required for drag operations so the target is not lost when the pointer leaves the element. The touch-action CSS property must suppress browser default gestures.
Cross-browser parity here is still uneven. One major browser raised its pass rate on the Interop pointer and mouse events test suite from 41% to 88% across the 2024 to 2025 cycle, a real gain. Even so, pointer events, canvas, and SVG are not among the Interop 2026 focus areas. That gap is more waterline. Real cost, quiet in the demo.
WHY CANVAS IS HARD TO MAKE ACCESSIBLE
A standard form field is a real DOM node, so the browser and screen readers understand it for free. A <canvas> is a single opaque rectangle of pixels. Everything drawn inside it, every button, handle, and layer, is invisible to assistive tech unless you hand-build a parallel accessibility model in JavaScript. That parallel model is the part the demo never shows and the part the calendar never plans for.
When building from scratch is genuinely the right call
There are four conditions where building a media editor from scratch is the correct decision, and this section is not a footnote. If you are in one of these, owning the whole stack is the rational choice, not a trap.
When the editor is the product, not a feature
If your product's value proposition centers on what the editor can do and how it does it, then the editor is not a feature inside the app. It is the app. Adopting an off-the-shelf layer would mean your differentiator runs on someone else's canvas, and that is a real strategic cost. When the editor is your IP, build it.
When your rendering needs are genuinely extreme
A custom WebGL or shader pipeline for real-time video effects or GPU-accelerated compositing may sit outside what any current browser editor supports at the depth you need. The honest test here is verification. If you have checked the gap against the candidate editors and the gap is real and not assumed, build.
When license cost at your scale exceeds in-house TCO
At large seat counts, licensing can genuinely cross over in-house total cost of ownership (TCO). Some off-the-shelf editors charge a flat per-developer-seat fee with no per-MAU (Monthly Active User) or per-edit caps and a perpetual license model, so "lock-in" and "cost at scale" are more nuanced than the cliche suggests. But if your seat count runs into the hundreds, a direct TCO comparison is worth running before you sign anything.
When compliance forbids third-party runtime code
Some regulated environments, government contracts, or enterprise security policies prohibit shipping vendor JavaScript the organization does not control. If that applies to you, the build decision is not economic. It is a compliance requirement, and adopting is off the table.
If any of these hold, building is the right answer and you can move forward with confidence. The rest of this post is the case where none of them do, which covers most teams handed "let users crop, annotate, and edit images inside our app." (If the build case is tempting but those specific technical constraints do not apply to you, the cost dynamics of a custom media build give a sharper picture of where the spend actually accumulates in practice.)
For everyone else, adopting an off-the-shelf editor changes the math
Adopting absorbs the whole iceberg on day one
For the common case, an off-the-shelf browser editor absorbs the entire iceberg. Undo and redo, selection state, theming, and accessibility are not features to be backlogged. They ship on day one. Editors in this category routinely include undo and redo, layer-based selection, and light, dark, and system theming out of the box, and the more mature ones now meet WCAG 2.2 AA. Some are commercially licensed, and some are open-source and free. Each one absorbs months of below-waterline work that your team would otherwise own and maintain forever.
The forward-looking layer is an agent-control surface
As agentic workflows mature, editors need a clean programmatic surface an AI agent can call without scraping the DOM or simulating pointer events. The Model Context Protocol (MCP) registry grew 407% since September 2025, reaching roughly 2,000 entries, with major productivity, payments, developer, and machine-learning platforms all publishing MCP servers for agent access. An ad-hoc canvas library built over a weekend has no structured surface for an agent to call. A production-grade editor either has one or can be wrapped to expose one. If you are putting AI editing into an agentic workflow, this is the layer that decides whether your agent can carry out the work directly or only point at where it should happen.
Where Layermetry fits as one of the adopt-path options
This is where the disclosure from the top pays off. Layermetry is a browser-only React editing layer that is embeddable into any product and agent-drivable from day one, not by roadmap promise. The undo stack, the accessibility layer, the pointer-event handling, and the programmatic control surface are not roadmap items. They are what the layer is.
It also ships native editing tools and lets your team ship your own tools alongside them, so adopting it does not mean giving up extensibility. For a team adding editing to a product or an agentic workflow that needs to ship this sprint without inheriting a multi-year canvas surface, that is the adopt path made concrete. It is one option in the decision, not the only one.
So which path is yours?
The demo is not the editor. That is the whole tension in one line. The Friday prototype is the 10% you can see, and the build-or-adopt decision is really about who owns the 90% you cannot.
Build if the editor is your IP, your rendering needs are extreme, your licensing cost at scale is prohibitive, or compliance requires it. On that path you keep total control and carry zero third-party dependency, and you pay for it in months of engineering time and indefinite maintenance. Adopt if the editor is a feature inside your product and you need accessibility, cross-device support, and an agent-control surface without building them yourself. On that path you ship this sprint and hand the upkeep to a vendor, and you accept a bounded surface and a live dependency in return. Both are honest answers. The right one is whichever column above describes your team.
For everyone outside the four build conditions, the month-three cost of owning the waterline is the number that decides it. To walk through how that math plays out for teams moving from a custom build to an adopted editing layer, see the technical decisions in our docs.