DEV Community: The State of Embed

The Fun Starts When You Stop Building Dashboards.

The State of Embed — Wed, 21 Oct 2026 16:30:00 +0000

I've spent the last decade building applications around analytics engines. I've spent the better part of a decade building applications around BI tools. I've built plenty of dashboards too, unfortunately. But the work I enjoy most is building web and mobile applications with custom interfaces, workflows and connections to other services. Occasionally, that means connecting things that probably had no business talking to an analytics engine.

After all these years, I'd still rather do that than build another sales dashboard. Dashboards are useful. People rely on them to do their jobs. But as a software engineer, there's only so much excitement I can get from putting another bar chart next to a KPI card. I'd rather build an application that uses analytics as part of the work someone is already doing.

That time we connected Qlik to Alexa

In my first article, I mentioned experimenting in the early days of Qlik Sense integrating with Amazon Alexa. Yes, Alexa. This was years before software vendors started putting a chatbot into anything with a screen. Yes! it's practical value was debatable, but it was very cool.

I doubt anyone was going to replace their dashboards with a smart speaker. I wanted to see whether I could use the Qlik engine through a voice interface. Ask a question, interpret it, send a request to Qlik and get an answer back. And it worked. I found that far more exciting than the latest chart type. I could build our own interface around Qlik's engine. I've approached analytics that way ever since.

Unpopular opinion

“I find traditional BI work a bit boring sometimes.”

“Data are fun” that was going to be the title of this blog before I settled on “The state of embed”. The data can be fascinating, I enjoy finding patterns and figuring out how things relate to each other. It's delivering the results that gets repetitive.

Another dashboard.
Another set of filters.
Another request to make the numbers bigger.
Another stakeholder who wants the entire application exported to Excel.

After enough of those requests, I start wondering why we deliver analytics this way. Why does someone need to leave the application they're already using to open a separate BI tool? Why should they have to set filters for a customer they've already selected? The application could pass that context to the analytics engine and show the relevant data. Then the user could act on what they find without leaving their work. That's the appeal of embedded analytics for me.

Stop making people go looking for analytics

Imagine you're building a customer management application. The application already knows which customer you're looking at and what permissions you have. An embedded analytics engine could use that context. You could show the customer's purchasing history and compare it with similar customers, all on the same screen.

You could also combine that data with information from other services or use it to trigger an action in another system. You control how the user explores the data. You can reuse the BI work you've already done.

If you've spent years building data models, business measures and security rules in Qlik, Power BI or Tableau, recreating them from scratch holds little appeal. I'd rather use those models and rules in an application with an interface I control. The engine handles the analytics. The application handles how people use the results. Getting the two to work together can be painful. I've written an entire article about my frustrations with qlik-embed.

What AI adds to the application

Lately, I've been thinking about what AI could add to these applications. AI generating dashboards doesn't excite me much. It's impressive. I wrote about it in my previous article. I'd rather use AI to help someone investigate data and act on it inside an application.

In the Alexa experiment, we had to write much of the logic for interpreting questions ourselves. The language tools available at the time were limited. LLMs, tool calling and MCP make those experiments easier to build today. Someone asks a question. The application supplies the context, the model chooses from the tools you've made available, and the analytics engine returns a result using its existing business rules and permissions.

You decide which users can access each tool and when an action needs confirmation. You can also connect the answer to other services. Imagine a user reviewing an unusual sales trend inside their CRM. They could investigate the numbers and inspect the relevant transactions there. With the right permissions, they could then create a follow-up task for their account manager.

Now that's something I'd enjoy building. None of this requires giving an LLM unrestricted access to your database. You can limit it to specific operations that enforce your existing permissions and business logic. You still have to get authentication, authorisation, data quality and error handling right. An LLM doesn't remove that work.

Why I keep building around analytics engines

Much of the discussion about embedded analytics focuses on business benefits. People use the data more, spend less time switching applications and make decisions sooner. Those are reasonable goals. I'm sure someone in a boardroom has a lovely PowerPoint explaining them.

My interest is more personal.

I like figuring out how to connect two systems that weren't designed to work together. I want control over the interface and what someone can do with the data. And I'd rather reuse an analytics engine's data models, measures and permissions than build all of that myself. That's what I enjoyed about connecting Qlik to Alexa.

Today's AI tools give me a way to try that idea again, with less hand-written logic for interpreting questions.

I still want to build applications where someone can ask about their data, investigate the answer and do something useful with it. Maybe above everything else l want to build something that leaves people asking "How in the state of embed did you do that?"

Everyone's a BI Developer Now. Apparently.

The State of Embed — Wed, 14 Oct 2026 17:34:54 +0000

AI can build your dashboard in minutes. Knowing whether the numbers are right is another matter.

I love AI.

I use it every day to write code, explore unfamiliar technologies, challenge my thinking and occasionally figure out why something I wrote three years ago makes absolutely no sense.
I'm also using AI to help write this article, which is rather ironic considering what I'm about to say.

But while I'm genuinely excited about what AI is making possible, I'm becoming increasingly uncomfortable with how quickly we're confusing the ability to do something with the ability to understand what we're doing. And nowhere is that becoming more apparent than in business intelligence.

Whatever happened to data literacy?

In my first article, I talked about Qlik's Data Literacy initiative and why I thought it was one of the better things the company had done.

I genuinely believed in it.

I was fortunate enough to have mentors who taught me about data, challenged how I approached problems and helped me build a career around something I initially knew very little about. Data literacy was about giving people the skills to question information, understand relationships and make better decisions.

Fast-forward to today, and we've got LLMs that can interrogate databases, generate SQL, create visualisations and explain the results without requiring someone to understand much about the underlying technology.

Recently, I watched a demonstration of Claude building dashboards and publishing them to Tableau. And I thought it was brilliant. Someone who's never touched Tableau can potentially create something useful in an afternoon. Someone learning BI can experiment without spending weeks figuring out which buttons to click.

I welcome that.

But the ease with which we can now create analytics has me wondering whether we're starting to undervalue the skills needed to understand them. Because learning how to build a dashboard was never supposed to be the point of data literacy.

AI is a skill multiplier

I've always maintained that AI is a skill multiplier. As a software engineer, I can use AI to build things faster, experiment with unfamiliar frameworks and learn concepts I might otherwise have spent days researching.

Sometimes it writes better code than I would have. Other times it produces absolute nonsense, and I spend longer explaining why it's wrong than I would have spent writing the thing myself. But I'm generally learning throughout that process. I can review the code, challenge decisions and recognise when something doesn't look right. And when I don't understand something, I have enough foundational knowledge to know what I need to investigate.

Now, give me the same AI tools and ask me to practise law. Would you trust me to represent you in court because I have a ChatGPT Pro subscription? I certainly wouldn't. So why should we approach business-critical analytics any differently?

Someone who doesn't understand data modelling, business definitions or even basic statistical concepts can now generate a dashboard that looks remarkably professional. That dashboard might even be correct. But would they know if it wasn't?

Using AI to accelerate learning is very different from using AI to avoid learning.

And I think that's a distinction worth keeping as these tools become more accessible.

Everyone's a BI developer now. Apparently.

With tools like Claude, Tableau Agent, Power BI Copilot and Qlik Answers, the technical barriers to analytics development are getting smaller. I've spent more hours than I care to admit formatting charts, dealing with obscure APIs and trying to explain why someone's preferred dashboard layout is a terrible idea.

If AI can take some of that work away, please do. But let's consider a fairly ordinary reporting scenario.

Imagine asking an AI assistant to build a sales dashboard.
It connects to your database, generates the queries and produces a rather impressive-looking dashboard showing that revenue has increased by 15%.

Excellent.

Except your business defines revenue differently from the way the model calculated it.

Perhaps cancelled orders weren't excluded. Perhaps customers were duplicated because of an incorrect join. Or perhaps the comparison includes a reporting period that shouldn't be there. The dashboard still looks fantastic. The charts work. The filters work. The numbers even reconcile with the SQL the AI generated. Unfortunately, the SQL is answering the wrong question.

Now, to be fair, some of the major BI platforms have already recognised this problem.

Qlik Answers can work with existing application logic and governed measures. Microsoft provides guidance on preparing semantic models for Copilot. These aren't necessarily systems handing an LLM unrestricted access to a production database.

Good.

That's exactly the direction these tools should be heading. But someone still has to define those measures, maintain the models and understand the business rules. And more importantly, someone needs to recognise when a technically correct answer is answering the wrong question.

We've spent years building semantic models, defining metrics, implementing access controls and establishing governance processes. I'd rather we didn't forget why we needed those things simply because someone demonstrated a particularly impressive dashboard in a five-minute video.

Trust, but verify

Anyone who's worked in software engineering should be familiar with this concept. We review code, write tests and validate assumptions before releasing applications into production.

At least, we're supposed to.

The fact that an LLM generated the code doesn't exempt it from review. So why would analytics be any different? If an AI-generated dashboard tells me revenue increased by 15%, I want to know;

Where that number came from?
What measure was used?
Were the correct filters applied?
Are the joins producing duplicate records?
Are we comparing the same reporting periods?
Who actually owns the definition of revenue?
And can I inspect the calculation rather than simply trusting the explanation the LLM has given me?

This doesn't have to mean manually checking every number on every dashboard. But for business-critical reporting, somebody should be able to demonstrate that the calculations are correct and the underlying assumptions are appropriate.

Otherwise, all we've done is automate the creation of something we don't fully understand. Which brings me to another thing that's been bothering me.

Are we even asking the right questions?

Conversational analytics.

Qlik Answers, Tableau Agent, Power BI Copilot and the growing number of MCP integrations promising to let us talk to our data.

I like the concept.

Being able to ask questions in natural language instead of navigating through endless dashboards and filters is genuinely useful. And some products are already suggesting follow-up questions and helping users explore their data. But I've been thinking about the limits of that experience.

Let's return to our sales dashboard.
It tells me revenue increased by 15%.
I ask the AI assistant why, and it explains that sales increased in three regions, with one product category performing particularly well.

That sounds useful.
And it is.

But what if the more important observation is that profitability has fallen?
What if that revenue increase came almost entirely from one customer?
What if the underlying data is incomplete?
Or what if we're comparing two periods that shouldn't be compared?

A good analyst might recognise those possibilities and investigate further. Someone without that experience might accept the explanation and move on.

To be clear, modern AI systems can identify anomalies, suggest investigations and surface relationships that a human might miss. With the right context and analytical capabilities, they could do this exceptionally well. That's the part I'm excited about.

But there's a difference between an assistant that helps me investigate my data and one that simply provides convincing answers to whatever I happen to ask.

What happens when people don't know which questions they should be asking?

It's something I keep coming back to.

We've made it easier than ever to ask questions about data. I'm just not sure we've spent enough time considering whether that translates into better decisions. Sometimes we're simply giving people a more expensive way to confirm what they already believe.

Perhaps AI could actually make us more data literate

This is where I think there's a genuinely interesting opportunity. Imagine an AI assistant that doesn't simply tell me revenue increased by 15%, but challenges how I'm interpreting that result.

It might point out that one customer accounts for most of the growth. It might flag that profitability moved in the opposite direction. It might explain why the comparison is potentially misleading.

Better still, it could show me the underlying calculations and help me understand why those details matter. I'd be far more interested in an assistant that challenges my assumptions than one that produces another beautiful chart.

And perhaps that's how we should be thinking about AI and data literacy.

I don't want to discourage anyone from experimenting with these technologies.

Quite the opposite.

If someone can build their first dashboard in an afternoon rather than spending weeks learning a BI platform, I think that's progress. If an experienced analyst can spend less time formatting visualisations and more time investigating what the data means, even better. But I don't think we should confuse removing technical barriers with removing the need for expertise.

The tools are getting better. The opportunities are enormous.

I'd just like us to put the same enthusiasm into helping people understand the results as we do into helping them generate them.

Because ultimately, if AI gives everyone the ability to create analytics, who's making sure they understand what they've created?

And would they recognise when it's wrong?

Qlik Embed: The Replacement for Capability APIs That Still Isn’t Ready

The State of Embed — Wed, 07 Oct 2026 18:35:21 +0000

I want qlik-embed to work. A simpler integration, modern authentication and less code to maintain should make moving away from the Capability APIs an easy decision.

I am using it now. OAuth integration was the deciding factor, with the push towards embedded AI adding another reason to switch. If I could have integrated OAuth as easily with the Capability APIs, I would have stayed with them without thinking twice.

Qlik calls it its primary embedding framework. For a straightforward chart, I can see why. For an application with extensions, maps, custom styling and its own error handling, the migration comes with compromises that are difficult to accept.

Performance improved, until I needed iframes

My first attempts appeared to load the same scripts across multiple charts. The overhead was enough for me to shelve the switch. Performance has improved massively since then, and Qlik deserves credit for that.

But the improvement feels uneven once I need iframe="true".

Legacy extensions still take me back to iframe rendering through classic/chart. Qlik documents experimental preview="true" support for extensions and more chart types in analytics/chart. UI documentation

In my testing, that preview behaves as read-only. I cannot make selections, and it adds an unnecessary outline around the charts. I couldn't find either behaviour explained in the documentation. Broader chart support is of limited use when I lose the interaction that makes Qlik useful in the first place.

The iframe fallback brings back the performance cost I was trying to escape.

Native charts should be the easy part

Maps are my clearest example. They are native Qlik charts, so I expected them to work through the modern chart component.

The current compatibility table explicitly excludes maps from standard analytics/chart support. Its classic/chart path requires an iframe. Qlik explains that tenant resources such as map tiles and uploaded images cannot currently be authenticated outside that mode. Chart compatibility

That helps explain the image failures I've encountered. It doesn't make the outcome any less frustrating. A native chart that needs tenant-hosted assets can send me straight back to the heavier rendering path. For maps, already expensive in my applications, that extra overhead has made the experience unusable in some cases.

Even branding can trigger the same compromise. Qlik documents that custom theme fonts need iframe mode when embedding across domains, with a possible performance impact. A font should not become an architectural decision. Custom theme documentation

Less integration code, less control

With the Capability APIs, I controlled more of the chart lifecycle. During migration, reproducing my global error handling, custom loading states, chart error messages and authentication retries has been harder than it should be.

There is still API access. refApi exposes the embedded app for operations such as selections and bookmarks. My frustration is with controlling the surrounding experience consistently. refApi documentation

One recent example was trying to remove or restyle Qlik's interaction blocker inside an embedded extension. My React application could reach the outer container, but the cross-origin iframe prevented it from changing the internal element. Moving that styling into Qlik meant depending on internal selectors that Qlik itself warns are unsupported. Qlik's CSS guidance

A small visual adjustment had become a tenant-side workaround. That is the loss of control I mean.

New features make the choice feel compulsory

Qlik Answers adds to the pressure. Its ready-made embedded experience is delivered through qlik-embed. It isn't something my existing Capability API integration simply gains. Assistant components

The documentation now labels ai/assistant as legacy and lists ai/agentic-assistant for the agentic experience. My rule with Qlik is simple. If it says legacy, I avoid it. In my experience, it brings more problems than it is worth.

The assistant still feels bolted on in my application. Getting it to match the surrounding typography, spacing and branding has been harder than I expected.

The Answers APIs provide another route for building my own interface. I appreciate having that option. It also means taking on more development to get the integrated experience I wanted from the component.

There are reasons to keep going

OAuth is a welcome standard authentication route, even though I've encountered session problems with Cloud hubs and embedded applications open together in the same browser. Qlik's authentication guidance is also far ahead of what I had a decade ago.

A component with a few parameters is easier to start with than manually orchestrating visualization calls. Nebula.js and picasso.js give me another way to build charts with more control, if I have the patience or enough AI tokens to do the work. Nebula.js and picasso.js

I use qlik-embed because it gives me the OAuth integration and access to new AI components I need. I still need reliable maps, images and extensions, alongside enough control to make them feel part of my application. Until those everyday requirements stop pushing me into costly workarounds, I can't call it a complete replacement.

How Did We Get Here? A Decade of Building on Qlik

The State of Embed — Wed, 30 Sep 2026 18:37:25 +0000

Let me get something out of the way first.

This is a frustration post.

I have been working in software engineering for more than 13 years, and I have been building with and extending Qlik since Qlik Sense 2.2.

I don't claim to know everything about Qlik. I don't claim to speak for every customer, developer, partner or user. But after spending the better part of a decade building real software around the platform, maintaining it, upgrading it, breaking it, fixing it and occasionally swearing at it, I think I have earned the right to have an opinion.

And my opinion is that somewhere along the way, Qlik stopped feeling like a platform that wanted developers around.

The frustrating part?

It wasn't always like this.

When building on Qlik was genuinely exciting

I started extending Qlik around the Qlik Sense 2.2 era, back in 2016.

And honestly, it was exciting.

Sense was still relatively young. The APIs weren't perfect. Documentation was very patchy. There were things you learned because somebody had figured them out, written a blog post about them, uploaded something to Qlik Branch or answered a question buried three pages deep in the Community. But that was fine. We understood that we were early.

More importantly, the platform felt like it was ours to experiment with.

Nobody was writing love letters to AngularJS, but it was stable. RequireJS wasn't exactly the future of frontend development either, but again: it worked. And once you understood the Capability APIs, extensions, mashups and the Engine API, you could do some ridiculous things.

Integrating D3?

Sure.

Building completely custom interfaces over the Qlik engine?

Absolutely.

Connecting Qlik to Amazon Alexa because somebody asked whether a dashboard could talk?

Why not?

There was a feeling that the Qlik engine was this incredibly powerful thing and the APIs were there to let you do whatever you could imagine with it.

The sky genuinely felt like the limit.

Qlik itself described Sense 2.2 as bringing "powerful new developer APIs and capabilities", including new app integration and visualization APIs. That was the direction of travel at the time: give developers more ways into the platform.

And around that technology, a community was forming.

Qlik Branch actually felt like a community

Qlik Branch mattered.

Not because everything on it was production-ready. It wasn't.
Not because every extension was brilliant. They weren't.
It mattered because people were building things.
People were experimenting.

People shared extensions, libraries, techniques and ideas simply because they thought they were useful.

At the launch of the Trusted Extension Developer programme, Qlik itself described Branch as a community of around 30,000 members sharing and collaborating on open-source projects.

Think about that for a second.

Thirty thousand people around an analytics platform, many of them creating things that Qlik itself hadn't thought to build.
That is incredibly valuable.
There was a sense that you were part of something bigger than whatever project you happened to be working on that week.

And the same Qlik also talked loudly about data literacy.
I loved that initiative. Maybe more than most.

I didn't come from some prestigious data science background. I was fortunate enough to have mentors who took the time to teach me about data, analytics and software. People shared what they knew with me, and eventually I built a career from it.

So the idea that data literacy shouldn't belong to some small group of specialists genuinely meant something to me.

Qlik made courses available for free through the Data Literacy Project and talked about making the ability to understand and challenge data accessible to everyone.

That was a version of Qlik I could believe in.
A great engine. An open developer ecosystem. Free educational initiatives. A growing community. It wasn't perfect. But it felt like it was going somewhere.

Then something changed.

From community to programme

Qlik Branch eventually gave way to a much more controlled ecosystem.

The Trusted Extension Developer programme — TED — was supposed to provide confidence that extensions had been tested for quality, security and compatibility. On paper, that makes perfect sense.

Enterprise customers need governance. You cannot install arbitrary JavaScript into production environments and hope for the best.
My problem wasn't the idea. My problem was the experience.

Getting through the process felt increasingly opaque. Applications appeared to disappear into a black hole. Waiting times could be ridiculous, and from where I was sitting it became much easier to find established vendors and partner-backed organisations in that ecosystem than the hobbyist developer who had built something interesting over a weekend.

Maybe that wasn't intentional.

But intent doesn't really matter when that is the experience your developer community has. The old feeling of:

"Build something cool and show us what you've made."

started feeling more like:

"Who are you, who do you work for, and what commercial relationship do you have with us?"

That is a very different developer ecosystem. And somewhere around that period I started feeling that Qlik was becoming less interested in developers who simply wanted to learn, experiment and build.

Then Qlik Sense Desktop stopped being free

For me, this was one of the clearest signals. On 14 July 2020, free access to Qlik Sense Desktop ended. From that point onward you needed to authenticate it against an appropriate Qlik Sense Enterprise or SaaS environment.

I remember thinking:

Why would you put another barrier between developers and your technology?

A developer downloading your product, experimenting locally, breaking things and learning your APIs is not a cost centre. That person might be the reason your product gets introduced into their next company. That student might become a consultant. That hobbyist might build an extension thousands of customers eventually use.

Microsoft understands this. AWS understands this. Cloudflare understands this. Stripe understands this. GitHub understands this. Developers need somewhere inexpensive — ideally free — to play.

For a while Cloud still provided a reasonably accessible route in.
Then that changed too. Today, Qlik Cloud Analytics Starter begins at $300 per month, billed annually, for ten users. That might be perfectly reasonable pricing for a small business buying an analytics platform.

It is not a playground. There is a difference. And I think Qlik has increasingly forgotten it.

The Cloud-first era

Then came the aggressive push toward Qlik Cloud. This is where things really started becoming difficult for me. I understand SaaS. I build SaaS applications. I understand rolling releases. I understand why vendors don't want dozens of supported versions running indefinitely. I understand CI/CD, feature flags, backwards compatibility and why sometimes things have to change.

What I don't accept is treating production integrations like collateral damage. When I build an application against somebody else's API, I am trusting them. If that application serves thousands of users, their API becomes infrastructure.

Changes matter.

And over the years I have seen Cloud changes break integrations, extensions and embedded applications in ways that have required urgent investigation from developers who changed absolutely nothing themselves.

To Qlik's credit, the developer changelog today is much better than what we had historically. Deprecations are increasingly documented and newer API namespace migrations promise defined notice periods.

Good.

That is exactly what should happen. But developers remember the incidents that got us here.

And then there was qlik-embed

For years, a huge amount of custom Qlik development was built using the Capability APIs.

Were they modern? Absolutely not.

AngularJS and RequireJS should probably be displayed in a museum at this point. But the Capability APIs were known. We understood them.
We understood their limitations. We understood their weird behaviours. And importantly, we had years of production knowledge around them.

Then came the next answer: qlik-embed.

Qlik now explicitly describes qlik-embed as its primary embedding framework and recommends it for new integrations. Conceptually, I agree with the direction. Web components. Modern authentication.
Better compatibility with browser restrictions around third-party cookies. React and Svelte integrations. A path away from AngularJS and RequireJS.

All sensible.

The problem is that developers don't build production applications from architecture diagrams.

We build them from APIs.

And especially during its earlier releases, trying to reproduce functionality that had become routine with the Capability APIs could become an exercise in figuring out whether something was unsupported, undocumented, broken or simply implemented completely differently.

Even today I regularly find things that should be straightforward turning into experimentation. Error handling remains one of my biggest frustrations. You shouldn't need archaeological skills to figure out why an embedded image failed to render.

You shouldn't need to experiment with three different approaches to perform something that sounds trivial.

And performance remains something I watch very carefully.

This is particularly frustrating because modern browser authentication is one of the strongest reasons to move. Qlik's current guidance pushes OAuth2 SPA and OAuth2 Impersonation for embedded Qlik Cloud applications, with qlik-embed sitting at the centre of that experience.

So eventually you aren't really deciding whether you like the new framework. You're deciding how long you can avoid migrating.

The API-key incident that finally got me

Then we come to the change that pushed me into actually starting this account, although it took me a while to get to it.

API keys.

Qlik deprecated the old Developer role and moved API-key management into the new Manage API keys permission model. Security-wise? Fine. Actually, I agree with the principle.

API-key creation should be governed by explicit permissions.

The problem is what happened operationally.

In environments I was responsible for, integrations that had been happily working suddenly weren't. Automations failed. Applications failed. Production systems that depended on API authentication needed intervention.

And while trying to work out what had happened, we eventually discovered that permissions needed to be changed.

Qlik's own changelog now acknowledges that users and groups which weren't migrated to the new Manage API keys permission may experience disruptions.

That sentence is doing quite a lot of work.

Because an "API disruption" isn't an abstract inconvenience when somebody has built production software around your platform. It means engineers being pulled into incidents. It means customers asking why something stopped working. It means somebody explaining that nothing changed in our release, but something changed underneath us.

And every time this happens, trust gets slightly smaller.

The frustrating thing is that Qlik is still brilliant

This is where I probably confuse anyone expecting this account to simply be a Qlik hate blog.

I don't hate Qlik. Quite the opposite. I think the Qlik engine is fantastic. The associative model remains one of the most interesting ideas in analytics. There are things I can do in Qlik that remain irritatingly difficult in competing products.

Even outside the Qlik community, you still see developers and BI practitioners saying exactly that. In one r/BusinessIntelligence discussion about moving from Tableau to Qlik, developers praised the associative engine and Qlik's flexibility.

In another discussion comparing alternatives to Power BI, people specifically called out Qlik's JavaScript embedding capabilities and Nebula as strengths.

So this isn't nostalgia from somebody refusing to learn another tool. The technology has real strengths. Which makes watching the surrounding developer experience deteriorate even more frustrating.

And now, obviously, AI

Because apparently no software article written in 2026 can avoid AI. Qlik has Qlik Answers. Qlik has agents. Qlik has MCP.

And to be fair, giving external LLMs access to governed Qlik data through MCP is genuinely interesting. I like MCP. I like the idea of connecting my own model to my Qlik tenant.

But even here there is a Qlik-shaped catch. Your LLM costs money.
Fine. Then your Qlik MCP usage also consumes Qlik Answers capacity.

Qlik's own MCP FAQ says that five MCP tool calls consume one Qlik question.

And your LLM subscription or API usage is separate. As of writing, Qlik Cloud Premium includes 1,000 Answers/MCP questions per month.
Which means developers building agents need to think very carefully about tool-call design.

An agent that wanders through tools unnecessarily isn't merely inefficient. It is spending your Qlik capacity while it thinks.
Build an agent badly enough and you can burn through a resource shared by everyone else surprisingly quickly.

This is the kind of detail that disappears underneath the words AI-powered analytics on a pricing page. It is also exactly the kind of thing developers actually need to talk about.

I'm clearly not the only person wondering what happened

One thing that pushed me toward writing publicly was looking outside the traditional Qlik bubble.

There was a 2024 Reddit thread from someone moving from Power BI to Qlik who basically said:

Where is everybody?

They could find endless Power BI material, but struggled to find equivalent Qlik communities, YouTube channels and independent resources.

Another developer replied that the Microsoft ecosystem simply has far more people publicly advocating for and teaching the platform.

That matters.

Communities don't die because somebody closes a forum. They die slowly. One person stops writing extensions. Another stops blogging. Someone else decides maintaining their open-source library isn't worth it. A consultant stops recommending the platform.

A developer looking for something to learn picks Power BI instead because they can download it and find 5,000 tutorials.

Eventually somebody asks:

Where did all the developers go?

Perhaps the better question is:

What reasons did we give them to stay?

So what is The State of Embed?

I don't know how much any of this can actually change. I'm one developer on the internet writing under a pseudonym.

Qlik is a large company with enterprise customers, revenue targets, shareholders, sales organisations, product roadmaps and priorities that are significantly bigger than whether I enjoyed building mashups in 2016.

I understand that.

But I also don't think that means those of us actually building on these platforms should stop talking about what they are like to use.

And that is really why this account exists.

This isn't going to be a weekly exercise in shouting Qlik bad, Power BI good or Tableau good, Qlik bad.

They all have problems. Trust me, we'll get to them.

I want to talk about embedded analytics from the perspective that rarely makes it into vendor presentations:

The person who actually has to build the thing. What works. What doesn't. What the documentation forgot to mention. What breaks in production.

What looks fantastic in a demo but becomes painful when you need to support 5,000 users. The API that saved three weeks of development. The API that stole three weeks of development. The clever workaround you probably shouldn't need. And occasionally, yes, the things that annoy me enough to write several thousand words about them.

Because the criticism here comes from somewhere important:

I still care about the product.

I want Qlik to be better. I want Qlik to be a platform developers are excited to discover again. I want someone with curiosity and a laptop to be able to stumble into Qlik, build something completely unnecessary with it on a Saturday afternoon, publish it on Sunday and accidentally start a career.

That world existed once.

I know because it helped create mine. Maybe we can't get all of it back. But at the very least, those of us who have been here long enough should stop pretending that nothing was lost along the way.

So this is The State of Embed.

No sales deck.
No Gartner quadrant.
No partner-approved messaging.

Just what happens when the dashboard ends...

and the code begins.