Why Smaller Qlik Sense Apps Win (And Why We Keep Having This Conversation)

[Qlik_DaveS]

I've been working for Qlik for over 13 years now — long enough to have done this dance in more than one job title.I had this exact conversation as a Technical Architect back when Qlik Sense was first released, whiteboard marker in hand, drawing boxes around "one app to rule them all." I'm having a version of it again now as a Senior Principal in EMEA Customer Success Engineering, just with a nicer title, a better chair, and the same slide. In between, I've outlasted a couple of UI redesigns and at least two rounds of "the app is called Sense now, not View." But there's one conversation that has outlasted all of it, resurfacing on a schedule so reliable you could set a reload trigger to it: "Can we just add this one more thing to the app?"

It starts innocently enough. Someone in Finance needs a KPI. Someone in Sales needs a different cut of the same data. Someone in Ops wants "just a quick tab." Fast forward eighteen months and you've got a single app trying to be sales dashboard, finance report, and ops control tower all at once — a data model so tangled that nobody, including the person who built it, fully understands what happens when you click on a single field. I've watched this exact story play out at more customers than I can comfortably count, across on-prem deployments and now Qlik Cloud tenants, and if I'd banked a dollar every time it happened I could've retired somewhere around year eight. Instead, here we are at year 13-and-counting, having the same conversation again, just with a different logo on the title slide and slightly greyer me delivering the same slide about section access.

So let's actually talk about why this happens, why it's a problem, and — more usefully — what to do instead.

The "kitchen sink" app is never a decision. It's an accumulation.

Nobody sits down on day one and designs a monolithic app on purpose. It's almost always the result of incremental requests layered onto something that started out perfectly reasonable. And the consequences compound rather than level off:

• Performance degrades. Every sheet shares the same in-memory data model, so calculation load scales with the whole app, not just the corner a given user is looking at. Reload times creep up for everyone, even people who only ever touch one small piece of it.
• Governance gets harder. Section access, row-level security, field-level rules — all of it multiplies in complexity with every use case folded in. One misconfigured rule can expose data across domains that were never supposed to touch.
• Change becomes risky. A tweak made for one stakeholder group can silently break something a completely different team depends on. Testing has to cover every use case sharing the app, not just the one you changed.
• Ownership gets murky. When Finance, Sales, and Ops all depend on the same app, nobody can approve a change without checking with everyone else first.

Why this matters differently on-prem vs. in the cloud

Here's a distinction that's worth being precise about, because it changes how the pain shows up rather than whether it shows up at all.

On a traditional on-prem Qlik Sense Enterprise deployment, one Qlik Sense Engine Service handles every app opened on that node, and all of those apps share the same pool of RAM and CPU. Qlik's own engine memory management documentation describes a configurable Working Set — Low and High memory thresholds, defaulting to 70% and 90% — that governs this. Below the Low threshold, the engine runs happily out of physical RAM. Cross the Low threshold, and it starts discarding cached results and Windows can start paging to disk. Cross the High threshold, and caching effectively stops altogether, which is exactly where Qlik's own guidance says performance and stability problems tend to surface. One oversized app pushing the whole engine toward that ceiling doesn't just hurt its own users — it's a noisy neighbour dragging down every other app on the node.

Qlik Cloud changes the picture. It's built on a cloud-native, Kubernetes-based architecture, with the Associative and Cognitive engines running as containers that scale horizontally with demand rather than sitting in one fixed-size shared process. That removes the worst of the static contention problem above — a single demanding app is far less able to permanently starve unrelated apps the way it can on a shared on-prem engine.

But — and this is the part people often miss — that doesn't make app size irrelevant in the cloud. A large app still reloads slower and is still slower to interact with, no matter how elastically the compute underneath it scales. And in consumption-based Qlik Cloud subscriptions, heavier reloads and larger data models simply translate into higher platform resource consumption. The governance and maintainability problems don't care which engine architecture you're running, either — those are organisational and design problems, not infrastructure ones.

Either way, the same conclusion holds: smaller, purposeful apps win. The savings just show up in a different place — shared server stability on-prem, versus consumption efficiency and responsiveness in the cloud.

The case for going small

Flip every problem above around, and you get the case for smaller, single-purpose apps almost point for point:

• Faster, more predictable performance — smaller data models load faster and evaluate faster on every selection, and RAM footprint per app becomes far easier to plan for.
• Cleaner governance — section access is scoped to a single domain, blast radius is contained, and one business owner can approve changes without a committee.
• Real agility — changes ship independently, without coordinating across unrelated stakeholders, and each app is small enough for a new developer to actually understand.
• Genuine reusability — a well-scoped app like "Regional Sales KPIs" or "AR Ageing" becomes a building block you can embed in multiple places without duplicating it.

That last point is the one that quietly unlocks everything else.

The catch: users still want one product, not five apps

Here's the objection I hear every single time I bring this up — I could genuinely narrate it in my sleep at this point, and once or twice I suspect I have: "Great, but our users don't want to hunt across five different apps to do their job. They want one thing to open."

Fair. Completely fair. Nobody has ever opened a Monday morning dashboard hoping for a scavenger hunt. And this is where a mashup earns its place as the presentation layer.

A Qlik mashup — built with qlik-embed web components or the Capability APIs — pulls visualizations, KPIs, and sheets from multiple underlying apps and arranges them inside a single, custom-built interface. Users never see app boundaries. They see one continuous product with a consistent shell: shared navigation, shared theming, and selections that can be synchronised across apps so filtering by date or region in one tab carries through to the next.

Critically, the mashup is a composition layer, not a data layer. It doesn't add another data model to maintain — it just presents. Each underlying app still gets reloaded, secured, versioned, and maintained completely independently. The user experience and the underlying data/logic scale separately, which is really the whole point of the modular approach.

A practical pattern looks like this:

1. Decompose the requirement into bounded domains (Sales, Finance, Operations, Customer Health) and build one small, purpose-built app per domain.
2. Build a mashup shell with a consistent design system — shared styling, a common header/tab structure, and a config-driven mapping of tabs to source apps and object IDs.
3. Embed objects from each app rather than rebuilding visualizations natively in the mashup.
4. Synchronise cross-app selections where it genuinely improves the experience, and leave the rest local.
5. Apply consistent naming, security, and reload standards across the underlying apps so they behave predictably as building blocks.

One size doesn't fit all

To be fair to the "kitchen sink" app: it's not always the wrong call. There are legitimate reasons to keep things consolidated in a single, larger app, and it's worth naming them rather than pretending they don't exist:

• A genuinely shared data model. If several teams are all working from the exact same facts, dimensions, and definitions with no meaningful variation, splitting that into separate apps just duplicates load logic and creates more places for the numbers to drift apart.
• Small scale, low complexity. A handful of sheets, one owner, one audience — the overhead of managing multiple apps and a mashup shell can cost more than it saves if the thing you're building is genuinely simple and likely to stay that way.
• Tight, well-understood governance already. If section access and row-level security are already simple and well-audited, splitting the app doesn't buy you much additional safety, and it adds another moving part to maintain.
• A single, dedicated owner and small dev team. Much of the maintainability risk described earlier comes from multiple stakeholders and multiple developers colliding. If that's not your situation, some of the sharpest edges of the "kitchen sink" problem simply don't apply.

The point isn't that every app must be split apart on principle. It's that the decision should be made deliberately, weighing these trade-offs, rather than arrived at by accident through eighteen months of "can we just add one more thing?" If you find yourself unable to answer "who owns this app" or "what happens if I change this field" with confidence, that's usually the signal it's time to split.

The bottom line

Big multi-purpose apps feel efficient on day one — one model, one place for everything. In practice, they age badly, and the cost of that growth compounds rather than levels off. Small, purposeful apps plus a mashup shell give you the operational and architectural benefits of modularity — performance, governance, maintainability, reusability — while still giving your end users the seamless, single-application experience they actually expect.

I'll go ahead and predict, with the confidence of someone who has been wrong about exactly nothing else in this post, that I'll be having a version of this conversation again sometime around year 15 — probably in whatever job title comes after this one. When that day comes, I already know what I'm doing: I'm not standing at another whiteboard. I'm pasting this link into the Slack thread and going to get a coffee.

For anyone who wants the fuller write-up this post is based on — with the engine memory mechanics, the on-prem vs. Qlik Cloud breakdown, and the full architecture pattern — I've attached the source document below.

---

Have you had to break up a "kitchen sink" app in your own environment? I'd love to hear how the migration went — drop a comment below.

[F_B]

Thank you for the helpful guide