13 Questions Teams Ask Themselves Before Choosing IMG.LY

Marc — Fri, 19 Jun 2026 09:00:00 GMT

Most teams evaluating an in-app editor arrive with the same shortlist of questions. These are the 13 that come up most across 600+ customers and 28 structured interviews, each answered straight, with the numbers behind it.

Why integrate an editor instead of building our own?

A production-ready SDK turns months of editor engineering into a couple of weeks of integration. Building an equivalent editor in-house runs 6 to 12 months and ties up two or three senior developers. The median IMG.LY customer reaches production within just 14 days, roughly 13× faster than the in-house route. For fast-moving companies especially, staying on your core is what pays off. Time spent on the editor is time not spent on what actually sets your product apart.

Can’t we just use an open-source library like Fabric.js, Konva, or Polotno?

You can, and some companies do. The problems start once you need more than a drawing surface. Open-source canvas libraries give you that surface and little else, no text on a path, no video timeline, no background removal, no cross-platform parity, and no ready-made UI. You build all of that yourself, and then you own the maintenance forever. The library is free, the year of senior engineering it takes to reach production quality is not.

It was very buggy, lack of features, not looking good, and we decided to not go deeper.

Engineering lead at a company that evaluated open source before CE.SDK

CE.SDK gives you the engine and the UI in one SDK, with the same rendering across web, iOS, and Android. If you want the full breakdown, we put open source next to building and buying in our Fabric.js comparison.

How fast can we realistically be in production?

A working prototype usually takes about two days, and a production-ready integration around two weeks. That time goes into wiring the existing SDK and API into your product and styling it to fit. Our AI developer tooling accelerates the process even more, giving your AI coding assistant full CE.SDK context for the integration. For fast-moving companies, this can be a real booster. Plai went from deal to live in about a month, then quickly scaled to thousands of ad campaigns with the new editor in place.

Every design edit request lands on my team. How do we scale that?

You stop being the bottleneck. Instead of your team producing every asset, users edit themselves inside your product, so output scales with your user base, not your headcount.

When you're dealing with a graphic designer who has a queue of work, you usually need to wait.

Product lead at an IMG.LY customer

The digital agency Digitas built its dealer portal on CE.SDK, and removing that bottleneck led to 85% of videos being created fully in-app, with active users making 3× more than before. None of that work routes through a design team.

The same engine also scales without anyone editing at all. Run it headless and it generates assets automatically. One template plus your data renders thousands of on-brand variants through the API. PostBuddy, for example, does exactly this. Its users choose a template, upload a CSV, and the engine auto-generates thousands of personalized, print-ready postcards, with no one editing a single one. Self-serve covers the one-offs, automation covers the scale.

Our users aren’t designers. How do we keep results on-brand without manual review?

With guardrails you set. Templates, locked brand elements, and constraints let a non-designer produce polished, on-brand work by default, because the editor only exposes what you allow. The output can even beat the professionals.

I built a better-looking asset in the portal than the agency ever did.

Martin Röhr — Senior Project Manager, Digitas

Nobody has to check the output later, because the guardrails already did.

We already have an editor. Is replacing it worth the costs?

The editing experience is part of the sale. When the flow is smooth, more users finish what they start, and completion is conversion. A clunky editor quietly costs you sales.

"Our brand didn't match our experience. You could see it in our bounce rates," says Tom Rowe, and the difference is easy to spot: "you can tell when competitors are using the old platform just by looking at it."

Tom Rowe — Product & Engineering, The Print Bar

When the status quo quietly costs deals, the editor should not be treated as a nice-to-have, but as an essential.

Will it match our product’s look and feel?

Yes, and that fit is exactly what an SDK gives you. The UI is fully customizable. You can theme it, restyle it, or drive the engine from your own interface in a headless setup. It acts as a native part of your product instead of a third-party tool bolted on. Swiss Post, which runs over a million personalized postcards a year on it, confirms this, calling CE.SDK “the only solution allowing a specialized, on-brand UI.”

We ship on web, iOS, and Android. Do we need three different tools?

No. One creative engine renders identically across web, iOS, and Android, so a template built on one platform looks the same on every other and your team keeps one mental model instead of maintaining three separate integrations. You build once instead of rebuilding the editor per OS.

Our users want AI features. Do we have to build those too?

AI editing ships inside the editor, not as a separate project. Background removal and generative tools like text-to-image and image-to-video are ready to use, and CE.SDK is bring-your-own-model, so you plug in the providers you want instead of running inference yourself. That can move the top line on its own.

We are seeing a 10x increase in new signups month over month in May — that was due to the fact that you can now auto-generate really beautiful-looking ads from scratch.

Hikari Senju — Founder & CEO, Omneky

Where does our users’ data actually go?

By default, processing happens client-side, in the browser or on the device, so images and video never touch our servers. For customers with strict data-security requirements that is often a deciding factor, and it is increasingly named as a must-have in AI-driven research. Nothing leaves the user’s machine unless you deliberately choose a server-side workflow. And since IMG.LY is based in Germany, GDPR compliance and EU data residency come built in.

If we build on this, are we locked in?

It is a fair concern, and a different one from whether the vendor sticks around. Your designs and templates stay yours. You can export both your scenes and the rendered output, as PNG, JPEG, PDF, and the scene file itself, and you can run the engine on your own infrastructure, fully headless if you want. You are integrating a component, not handing your data model to someone else, and switching the component out later is possible.

Can we depend on this provider when it matters?

IMG.LY is an established company based in Germany, with a real team of people behind the product rather than a side project that could disappear next quarter. 600+ organizations, from startups to large global enterprises and government agencies, run the SDK in production, together generating around 500 million creations a month. Names on that list include Mercedes-Benz, Lufthansa, SAP, Polaroid, and Ticketmaster. You also get a dedicated contact who stays reachable when you need help, not an anonymous ticket queue, and the SDK keeps shipping new capabilities release after release, so the foundation you build on only gets stronger.

How do we know it’ll work before we’re all in?

You don’t have to trust the pitch, you can prove it yourself. The trial is self-serve. A developer can spin up an account and start building with the real SDK without going through sales, then judge the integration and the docs firsthand. It doesn’t need to take long either, thanks to the AI developer tooling that helps your assistant generate accurate integration code. That’s how most teams who picked IMG.LY decided, because seeing it run in your own stack removes the guesswork before you commit.

Recognize a few of these?

These are exactly the questions a careful team should ask before building on someone else’s technology. If you’re working through them, we’re glad to help: try the SDK yourself or contact our team. Reaching out is no commitment, and we’re happy to dig into your specific case. And to see how it played out for other companies, our case studies offer interesting insights.

Marc – IMG.LY Blog