Build or buy, now that building is cheap

Image and video editing looks finite from the outside: a canvas, a few tools, an export button. That impression is short lived. An AI agent will give you a working canvas with text, shapes, layers and a PNG export in a day, and it will be good enough to demo. The problems show up later, when a Safari upgrade breaks text rendering, when a customer uploads a 400MB PSD and the tab runs out of memory, and when undo and redo get out of sync between two people editing at once.

Once an editor is in production, it stops behaving like a feature and starts behaving like infrastructure. This guide is a breakdown of who owns what once your editor is live, and what real teams have spent (in dollars, in months, and in attention) to find out.

We sell Polotno SDK, so we are biased toward "buy." But the cases below are specific enough that you can run the math yourself. Before anything else, here is the part that has genuinely changed.

If all you need is a canvas with text, shapes and an export button, you do not need six months of engineering and you probably do not need us.

Generate it and move on. This guide is about what happens after that point, and about the cases where a basic editor was never going to be enough.

AI has made it much cheaper to start. The responsibilities that come after launch are the same as they were. Building gives you full control of the editor and full responsibility for every regression, browser change, and performance problem that follows. Licensing reverses that. The vendor carries the responsibility, and the price you pay is depending on them.

The right call depends less on what you ship in v1 than on what you're willing to own in v10.

1. What capabilities do you actually need to own?

Start with the obvious list: text, shapes, layers, templates, export. Then add what shows up after launch: high-resolution assets, video timelines, large-canvas performance, branded templates, real-time collaboration, font fallback, kerning, RTL text, PDF export with embedded fonts, and the dozen export formats your customers will eventually demand.

Each of these is a maintenance contract rather than a one-time build, and the work arrives in a handful of recognisable categories.

1.1 A newer version of this problem

Code written by an AI agent is still code your team owns, even though nobody on the team wrote it. A prototype gets to about ninety percent in a day. The remaining ten percent is font fallback, kerning, right-to-left text, colour management and memory behaviour on real customer files, and that ten percent was always the expensive part. What is new is that your team may not understand the other ninety percent either.

Then there is everything that sits outside the canvas entirely, from server-side rendering and file interchange through to print output and validation. The editor's surface area is rarely the editor itself.

The real question is which of these responsibilities you want on your roadmap forever.

2. Is the editor your differentiation, or your dependency?

A media editor can be central to your product without being owned by your team.

If the editor is the product you sell, owning it is the business. For everyone else it is plumbing, and everyone else is where most of this work actually happens: print and packaging, regulated content, ecommerce personalisation, digital signage, brand asset portals, certificate and document generation. The differentiation lives one layer up: the AI model, the data, the workflow, the distribution.

A useful test, and it is a harder one now: if a competitor generated a comparable editor over a weekend, would they have your business? If the answer is yes, the editor was never what made you hard to compete with. Build the layer above it and license the layer below.

Predis.ai is a clear example. In 2026, being an AI marketing platform describes a whole category rather than an advantage, so their advantage has to come from somewhere else: the campaign workflow and the account data they have built up. It was never going to come from the canvas. They embedded Polotno, launched in under two weeks, and now serve more than 100,000 users a month without anyone on staff maintaining an editor.

Phamax is the same shape with higher stakes. Ariya, their pharma-trained AI platform, generates compliant drafts that brand and omnichannel teams still have to refine, so some kind of editor was unavoidable. Their own estimate was two to three months to build something stripped down, and up to a year to make it production-grade, in a market where a compliance gap is not a bug ticket. None of that work would have improved the domain-trained AI that is their actual advantage. They embedded Polotno in about two weeks and kept the roadmap.

3. What does each path actually cost?

There are three separate costs here, and they used to get quoted as a single number. Pulling them apart is most of the work.

3.1 Getting to a working demo

This has become very cheap. An engineer working with an AI agent can have a canvas with layers, text, drag handles and a PNG export running in a day or two. It will not be a toy, and it will hold up in a demo. Anyone quoting six months for this part is working from an old estimate.

3.2 Getting to production

This has not changed much. A demo handles the files you gave it. Production handles the files your customers give you, which includes the 300MB PSD with forty layer groups, the font with no bold weight, the Arabic text that has to be shaped and mirrored, the CMYK image that has to keep its colour on export, and the iPad with a third of the memory you tested on. Closing that gap still takes months, and AI does not shorten it much, because the difficult part was never typing the code. The difficult part is knowing which edge cases actually happen.

3.3 Owning it for three years

This has got harder. You end up with a large codebase, written quickly, that nobody on the team wrote line by line. When a rendering bug appears in year two, whoever picks it up is reading unfamiliar code under time pressure. Inheriting a system you did not write has always been a risk. What is new is that this can now happen with code your own team produced.

HUMElab estimated their internal build at roughly ten months. Heirloom's team described "months of development and substantial investment" as the alternative they walked away from.

The build cost is the down payment. Maintenance is the mortgage.

Once live, your team owns every browser regression, every export bug, every performance problem on a 4K canvas, every collaboration desync, every font that renders differently on Windows. We used to quote an industry benchmark here, 20 to 30 percent of the build cost per year. We have dropped it, because once the build cost stops being a fixed number, a percentage of it does not tell you much. The more useful measure is attention. There is usually one engineer who understands the text layout code, and that engineer gets interrupted every time it breaks. That cost does not appear on any budget line, and it does not get smaller because an AI wrote the code.

Licensing flips the cost structure.

Whatever a licence costs, it is a known number that you agree in advance. It has a ceiling, and it is tied to the scope of what you are doing rather than to your headcount or to a backlog of bugs you have not found yet. You can put it in a budget and it stays there.

The honest comparison is between owning this indefinitely and paying someone else to share the operational load. Run the math at year three and year five, as well as at launch.

Some teams make the call explicitly. Others arrive there after scoping what ownership would actually mean.

4. Would building actually give you a competitive edge?

In-house only creates an advantage if owning the editor is what makes you hard to compete with.

If your differentiation lives in the editor itself (specialized print workflows, proprietary timeline rendering, novel UX patterns that no SDK ships), build it. The editor is the product.

If your differentiation lives anywhere else (the AI model, the data graph, the distribution, the workflow above the canvas), building the editor distracts from your moat instead of widening it. You spend a year on the last ten percent of canvas work, which is the only part that ever took a year, while the competitor who licensed an editor ships their actual product.

That's how BrandNinja approached it. Editing was necessary to deliver the product, but the team's leverage was somewhere else. Licensing let them launch faster and stay focused on the parts of the product that defined their position.

5. What happens at year three?

The short-term trade-offs are easy to see, and the long-term ones are not.

Build in-house and you eliminate vendor dependency, but inherit permanent internal ownership. The editor needs to keep up with browser releases, new file formats, rising user expectations, and the slow accretion of edge cases. If maintenance slips, the editor actively degrades the product: blurry exports, broken fonts, "why does it crash on iPad?" support tickets that compound into a churn problem.

AI makes this risk larger rather than smaller.

A codebase put together in a few weeks by people who were reviewing suggestions rather than writing the code is a codebase that fewer people understand. The old version of this problem was that the original engineers eventually leave. The newer version is that you can reach year three without anyone having understood the code in the first place.

License an editor and you accept a different risk: the vendor changes terms, raises prices, or sunsets the product. The right contract neutralizes most of this. Polotno enterprise customers can pin versions, get optional source code access, and negotiate liability and SLA terms, turning the worst-case migration into a planned project rather than an emergency.

Neither path eliminates risk. The question is which kind of risk your team is structurally better at managing: a vendor relationship, or a permanent internal commitment to a non-core system.

Peleman's case is a clear illustration. Their challenge was doing it again and again, reliably, at scale, across years and product lines. That's where in-house ownership stops looking like control and starts looking like a tax.

6. Where this is still a real decision

The build versus buy question now applies to a narrower set of cases than it used to.

If you need a canvas with text, shapes and a PNG export, build it. You will have it this week, and licensing an SDK for that is more than you need.

The question is still a real one in the cases where a basic editor was never going to be enough.

6.1 Print and physical output

CMYK separations, spot colours, ICC profiles, bleed and trim, PDF/X compliance, imposition and overprint. A screen is forgiving about colour and a printing press is not. If a colour shifts between the preview and the plate, you get a reprint bill and a customer who does not order again.

6.2 High volume server-side rendering

Thousands of renders an hour, running headless, producing the same output today and in eighteen months across font updates and browser versions.

6.3 Variable data and automation

One template and fifty thousand versions of it, all of which have to be correct without anyone checking them.

6.4 Anywhere a mistake costs someone else money

Regulated labelling, packaging artwork, and anything where the file leaves your system and gets printed.

In these cases the editor stopped being a feature some time ago and became critical infrastructure. They are also the cases where an AI agent will produce something that looks correct and is wrong in ways you only find out about later, at volume, on paper. Our print and packaging page covers how this works in practice.

7. The decision

Build vs buy is a commitment to an ownership model.

7.1 Build in-house if the editor is the product

Own it for years, fund it as a first-class team, and accept that it will absorb engineering capacity forever.

7.2 License if the editor is infrastructure

HUMElab integrated in under a month, Heirloom in two weeks with one developer, and Someli in three weeks. Shipping quickly matters less than it used to, because most teams can do that now. What those three have in common is that none of them employs anyone to maintain an editor today.

The teams that get this wrong rarely fail at launch. They fail at year three, when a "good enough" internal editor quietly becomes critical, the original engineers have moved on, and nobody wants to touch the canvas code.

The teams that get it right decide explicitly. They pick the ownership model that matches their strategy over the full life of the product.