Power Apps Are Underrated for MVPs

Jun 14, 2026 | Articles

ARTICLE

Power Apps are underrated for MVPs

Power Apps may not be the final system, but they’re a practical way to test workflows and avoid building the wrong solution.

By Dami O. | 06/14/26

Power Apps don’t get much respect

They’re often dismissed as throwaway tools or something to avoid if you care about “doing it right.” What we’ve seen is different. When used intentionally, Power Apps are one of the most practical ways to test automation ideas before turning them into something permanent. When clients tinker with Power Apps, it helps everyone.

Instead of debating requirements in meetings, workflows get exercised in real work. You learn very quickly what actually matters, what people ignore, and what creates friction once it’s used day after day. That information is hard to get any other way. From our side, early Power Apps give us clarity.

Sometimes what a client has built makes sense to keep with better structure and guardrails. Sometimes it needs cleanup, clearer data definitions, and ownership. And sometimes it becomes obvious that the logic and data need to move into Azure with a proper database and service layer for feasibility and scale.

That decision is easier when the workflow has already been tested.

Power Apps also surface bad assumptions early. Not bad intentions, just ideas that sounded valuable until they were used daily. Finding that out early saves time, money, and rework.

SharePoint isn’t a database, and it shows once data volume grows or relationships matter. Performance drops with larger datasets. Collaboration can slow down since canvas apps don’t support true multi‑author editing. Complex logic becomes harder to reason about. Licensing can also escalate quickly once premium connectors or external users are involved.

Those limits tell you when you’ve learned enough and it’s time to engineer something more durable. Used that way, Power Apps help you better define the systems you need.

Build First, Prove Value Fast

Power Apps Make That Possible

SEE RESULTS NOW

Where accuracy matters most
that's where we work

We work anywhere documents carry risk, financial impact, or compliance requirements.

What you're probably
wondering

Quick answers to the most common questions

What are the pros and cons of using Power Apps?

Power Apps are fast to build, integrate well with Microsoft 365, and are effective for testing workflows and automation ideas with real users. They reduce upfront engineering effort and surface requirements early.
The downsides are scale and complexity limits. SharePoint is not a true database, performance drops with large datasets, collaboration is limited in canvas apps, complex logic can get hard to manage, and licensing costs may rise as apps mature.

Are Power Apps good for production or only prototypes?

Power Apps can be used in production for lightweight, well‑defined workflows. They are especially strong as MVPs and early operational tools. As data volume grows, workflows become core processes, or reliability and performance requirements increase, many teams move logic and data into Azure services while keeping Power Apps as a front‑end or validation layer.

When should you not use Power Apps?

Power Apps are not a good fit when you need high‑volume transactional systems, complex data relationships, heavy concurrency, or long‑term extensibility with strict performance guarantees. They are also less suitable when multi‑developer collaboration or fine‑grained control over backend architecture is required. In those cases, traditional application development is usually a better choice.

VIEW ALL QUESTIONS

Shadow IT as an Early Warning System

Jun 14, 2026 | Articles

ARTICLE

Shadow IT as an early warning system

Shadow IT usually exists because work still needs to get done and official systems don’t quite meet the need. This piece explains why shadow IT is often an early warning system, not a failure.

By Dami O. | 06/14/26

Why teams bypass IT

Shadow IT" usually gets talked about like a discipline problem. Teams building things they shouldn't. Tools showing up without approval. Processes moving outside official systems. The implication is that people are being reckless or ignoring policy. That's almost never what we see. Most shadow IT exists because work still needs to get done. When teams build things on the side, it's usually because the official path is too slow, too abstract, or disconnected from how the work actually happens.

They're not trying to bypass IT. They're trying to keep things moving. Shadow IT" usually gets talked about like a discipline problem. In practice, shadow IT shows up in very predictable ways. Teams building things they shouldn't. Tools showing up without approval. Processes moving outside official systems. The implication is that people are being reckless or ignoring policy. That's almost never what we see. Most shadow IT exists because work still needs to get done.

When teams build things on the side, it's usually because the official path is too slow, too abstract, or disconnected from how the work actually happens. They're not trying to bypass IT. They're trying to keep things moving. Spreadsheets that quietly turn into systems. Power Apps that start as a form and end up running a workflow. Shared folders that become a source of truth because no one else offered one.

These aren't just acts of rebellion, they're signals. They tell you that there's demand for automation, structure, or visibility that isn't being met through the official channels. Labeling that as a failure misses the point. The more useful question is: what problem is this team solving that no one else stepped in to address?

Where things go wrong

Shadow IT becomes a problem when it stays invisible for too long. When no one knows who owns a tool. When logic lives in one person's head. When a solution becomes critical without guardrails, support, or a plan. That's when risk creeps in.

Not because the tool is "unauthorized," but because it's unsupported. The irony is that cracking down often makes this worse.

Teams just get better at hiding what they've built, which pushes risk further underground.

The healthiest automation environments we've seen all do the same thing. They treat shadow IT as input instead of something to stamp out.

Turning shadow IT into signal

When a team brings a spreadsheet, a Power App, or a side system to the table, we don’t start by asking why it exists. We ask what it’s taught them.

What work does it actually support? Where does it break down? What parts feel fragile? What parts are working surprisingly well?

Those answers are incredibly valuable. They let you see the real workflow, not the idealized one. From there, decisions get easier.

Some solutions just need structure and clarity.

Some are fine to keep with guardrails. Some clearly need to move into a more durable architecture.

Partnership changes the dynamic

The moment teams feel safe sharing what they’ve built, the entire dynamic shifts.

They stop defending their solutions.
They stop hiding shortcuts.
They start asking better questions.

That’s when automation becomes collaborative instead of adversarial.

IT and engineering stop being gatekeepers and start being partners. The goal moves from “prevent shadow IT” to “make sure important work is supported properly.

A mindset shift worth making

Shadow IT isn’t just rebellion, It’s evidence. Evidence that people care enough about their work to build something when nothing exists. Evidence that there’s opportunity to improve how systems get introduced and supported.

Ignoring it or condemning it throws away that signal. Listening to it, understanding it, and responding thoughtfully turns something risky into something genuinely useful. And that’s usually where the best automation conversations actually begin.

Shadow IT exposes gaps in business systems

Bring hidden workflows into the light

LET'S DESIGN BETTER SYSTEMS

Where accuracy matters most
that's where we work

We work anywhere documents carry risk, financial impact, or compliance requirements.

What you're probably
wondering

Quick answers to the most common questions

What is shadow IT and why do teams bypass IT?

Shadow IT refers to tools and systems created outside formal IT processes. Teams typically bypass IT not to ignore policy, but because official solutions are too slow, too abstract, or don’t reflect how work actually gets done. In many cases, shadow IT is a practical response to keep operations moving when existing systems fall short.

Is shadow IT a risk or a sign of unmet business needs?

Shadow IT can introduce risk when tools lack ownership, documentation, or support. But more often, it signals unmet demand for better workflows, automation, or visibility. Organizations that treat shadow IT purely as a compliance issue tend to miss the underlying problems it’s pointing to, while those that investigate it can uncover meaningful opportunities for improvement.

How can companies manage shadow IT without slowing down critical work?

Managing shadow IT effectively means treating it as input rather than something to eliminate. By evaluating what teams have built, companies can decide which solutions need structure, which can remain lightweight, and which should evolve into more scalable systems. This is the approach XINDARA takes—working with organizations to surface these tools, reduce hidden risk, and align them with more durable system design without disrupting the work they support.

VIEW ALL QUESTIONS

Governing EUCs Without Disrupting How Banks Work

Jun 14, 2026 | Articles

ARTICLE

Governing EUCs without disrupting how banks work

Learn how governing EUCs effectively means building guardrails that work with how banks actually operate, not against it. Flexibility and control are not mutually exclusive, and the best EUC strategies treat them that way.

By Dami O. | 06/14/26

Govern EUCs with Flexibility

Once you accept that End User Computing tools are part of how banks actually work, the next question becomes more interesting. How do you govern them without removing the flexibility that made them necessary in the first place?

This is where many EUC conversations stall. The default response is usually control through restriction. Lock down access. Centralize everything. Force usage of a single platform. On paper, it sounds clean. In practice, it rarely holds. A better approach to governing EUcs starts by rethinking what EUCs are allowed to be.

EUCs are not systems of record

One of the most useful shifts we’ve seen is separating where truth is defined from where work happens.

EUCs should not define authoritative data. They should not be the place where core business logic quietly lives. That role belongs upstream, in governed data platforms.

EUCs are often the most effective effective interface for analysis, validation, and decision‑making.

That duality is not a contradiction, it’s a design opportunity.

The Lakehouse as an authorized redistributor

Modern Lakehouse architectures make this separation easier than it used to be. When a Lakehouse is treated as the system of record, its role doesn’t end with storage. It becomes the authorized redistributor of curated data products.

Instead of allowing EUCs to pull arbitrary tables or rebuild logic independently, teams consume certified datasets. Clear grain. Defined metrics. Documented ownership. Versioned outputs.

This matters from a governance perspective. You can trace where data came from without needing to police every spreadsheet formula.

An EUC becomes a governed consumer rather than an uncontrolled source.

Importantly, this doesn’t mean users need to query the Lakehouse directly or abandon their tools. It means the Lakehouse establishes boundaries that EUCs operate within.

Guardrails don’t have to slow people down

One reason EUC controls fail is that they’re implemented as barriers instead of channels. Blocking Excel access or forcing complex tooling on unready teams doesn’t eliminate EUCs. It just makes them harder to see.

We’ve seen better outcomes when banks provide sanctioned ways to consume data. Approved connectors. Reusable templates. Clear guidance on what’s acceptable and what isn’t.

Power Apps that read from curated APIs instead of SharePoint lists standing in for databases.

Excel models wired to certified datasets. Power BI semantic models backed by Lakehouse data. When the approved path is easier than the unofficial one, behavior changes without enforcement.

Proportional governance actually works

Not all EUCs deserve the same level of scrutiny. Banks that govern EUCs effectively do so proportionally. Low‑risk, exploratory tools stay light. Material EUCs that support regulatory reporting, risk metrics, or controls get stronger oversight.

That oversight doesn’t have to look like a full SDLC

It usually means clear ownership, documented intent, versioning discipline, and lineage back to trusted inputs. The key is that decisions are based on impact, not on the existence of an EUC itself.

Where this breaks down

Problems emerge when EUCs are expected to either disappear or behave like enterprise applications. Neither expectation is realistic.

EUCs struggle when they’re asked to scale endlessly. SharePoint starts acting like a database. Logic becomes tangled. Performance degrades. At that point, the EUC has done its job. It has shown where the work actually lives.

The mistake is treating that moment as failure instead of a signal. That’s when a workflow transitions into a more durable architecture, not because policy demands it, but because the reality of use does

The role companies like ours play

This perspective shapes how we work with banking clients. We don’t start EUC conversations with a mandate to rebuild. We start by understanding how practitioners are actually working today and what those tools are already telling us.

Which EUCs are exploration layers on top of trusted data. Which ones are compensating for missing functionality. Which ones have outgrown their original purpose. From there, we help banks decide what needs structure, what needs guardrails, and what needs to move upstream. Often, the most effective path is strengthening the boundary between the Lakehouse and the EUC, not eliminating the EUC itself.

That was especially true in the context of regulatory findings. Well‑governed EUCs made lineage clearer, remediation faster, and practitioner confidence higher than forcing everything into rigid platforms that didn’t reflect the work.

Realistic EUC governance for modern banks

Control risk without slowing down work

BUILD YOUR EUC GOVERNANCE

Where accuracy matters most
that's where we work

We work anywhere documents carry risk, financial impact, or compliance requirements.

What you're probably
wondering

Quick answers to the most common questions

How can banks govern EUCs without limiting flexibility?

Banks can govern End User Computing tools by separating where data is defined from where work happens. Core data and business logic should live in governed platforms, while EUCs are used for analysis, validation, and decision-making. This approach preserves flexibility while reducing risk, instead of relying on restrictive controls that slow teams down or push work underground.

What role does a Lakehouse play in EUC governance?

A Lakehouse acts as the system of record and the authorized redistributor of trusted data. EUCs consume certified datasets with clear definitions, ownership, and lineage rather than rebuilding logic independently. This makes EUCs governed consumers of data instead of uncontrolled sources, improving traceability without forcing users to abandon familiar tools.

What does proportional EUC governance look like in practice?

Proportional EUC governance applies oversight based on impact, not on the mere existence of an EUC. Low-risk, exploratory tools remain lightweight. Material EUCs that support regulatory reporting, risk metrics, or controls receive stronger guardrails such as clear ownership, documented intent, versioning, and lineage. This keeps governance practical and aligned with how banks actually work.

VIEW ALL QUESTIONS

The Fabric Trial Made Power BI Easier to Introduce

Jun 13, 2026 | Articles

ARTICLE

The Fabric Free Trial Made Power BI easier to introduce

The 60‑day Microsoft Fabric trial has become a practical way to explore Power BI without early commitments or guesswork.

By Dami O. | 06/13/26

Transition to Power BI

Moving teams from Excel dashboards to Power BI is often straightforward. Where progress tends to slow down is timing. Some teams do not feel they need Power BI yet. Others know they will, but the moment never quite feels right. Licenses feel like commitment. Requirements feel premature. Decisions get pushed out because it is unclear what people will actually use once something is built.

Many of these teams already rely on dashboards, often in Excel. They work well enough, and people understand them. When Power BI enters the conversation too early, it can feel like a solution looking for a problem.

The 60-day Microsoft Fabric free trial has given us a better way to approach these situations by removing pressure rather than forcing a decision. Instead of explaining why Power BI is useful, we connect real data and build a small set of dashboards that reflect how the team already works. People can filter, drill, and explore familiar metrics during their normal day instead of imagining how the tool might fit. That shift quickly changes the conversation from whether to adopt Power BI to what it can do in practice.

Training without commitment

There are teams that rely on dashboards, often in Excel. They work well enough and people understand them. When Power Bi enters the conversation too early, it can feel like a solution looking for a problem.

The Fabric free trial changes that tone. Instead of explaining why Power BI is useful, we can connect real data and build a small set of dashboards that reflect how the team already works. People can filter, drill and explore during their normal workflows instead of imaging how it might look and feel.

That tends to surface questions quickly. Not "should we do this" but "can it do this..." and "what happens if..."

These are much better conversations to have because requirements gathering changes when people can react to something.

Letting requirements emerge

During the trial, we can test different visuals, data models, and refresh approaches against actual usage. Some ideas turn out not to matter. Others become more important than expected. Performance questions show up that wouldn’t have been obvious on paper.

That feedback loop usually leads to tighter scope and fewer surprises later.

By the time the trial ends, teams aren’t guessing anymore. They’ve lived with the dashboards long enough to know what’s worth investing in.

A gentler move off Excel dashboards

For teams that are coming from Excel dashboards, the Fabric free trial often serves as a transition period. Excel doesn’t need to disappear immediately. Dashboards don’t have to be ripped out. Instead, Power BI starts to take on responsibility where it clearly adds value, while Excel stays in the background until it no longer makes sense to grow there. That overlap helps teams build confidence without feeling rushed.

Why this has been useful

Teams can explore Power BI without committing too early. They can train people, test assumptions, and evaluate licensing needs based on real usage instead of forecasts. When a decision is finally made, it’s informed by experience, not pressure.

For clients who weren’t sure they needed Power BI yet, or knew they did but hadn’t found the right moment, that has made a real difference.

What the Fabric free trial really provides is optionality.

Freedom to explore without committing.

TRANSITION TO POWER BI NOW

Where accuracy matters most
that's where we work

We work anywhere documents carry risk, financial impact, or compliance requirements.

What you're probably
wondering

Quick answers to the most common questions

Is Power BI worth moving to if our team already uses Excel dashboards?

Yes, especially when the move is gradual. Many teams rely on Excel dashboards because they’re familiar and effective. Power BI becomes valuable when teams need better interactivity, scalability, and shared access. Using the Microsoft Fabric free trial allows teams to explore Power BI with their existing data and workflows, see where it clearly adds value, and transition only where it makes sense, without abandoning Excel prematurely.

How can teams evaluate Power BI without committing to licenses too early?

The 60‑day Microsoft Fabric free trial provides a low‑risk way to evaluate Power BI using real data and real use cases. During the trial, teams can build and use dashboards, train users, and observe actual behavior to determine who needs creator, consumer, or occasional access. This removes guesswork from licensing decisions and replaces upfront commitments with evidence from real usage.

What’s the best way to gather Power BI requirements before implementation?

The most effective way to gather Power BI requirements is to let them emerge through hands‑on use. During a Fabric free trial period, teams can test visuals, data models, and refresh patterns against day‑to‑day usage. This surfaces performance needs, clarifies what matters most, and often reduces scope. By the time implementation decisions are made, requirements are based on lived experience rather than assumptions.

VIEW ALL QUESTIONS

Knowledge Loss: What Happens When Bill Leaves?

Jun 8, 2026 | Articles

ARTICLE

What happens when
Bill leaves

Explore why knowledge loss is inevitable when critical company information lives in inboxes, emails, spreadsheets, and people's heads, and how simple, grounded automation keeps it accessible long after "Bill" is gone.

By Dami O. | 06/08/26

Keeping Bill's knowledge alive

Every company has a Bill. He is the person who remembers how things started, why certain choices were made, and what to watch out for. He knows the shortcuts that save time and the traps that slow everything down. He carries years of context that no one else has.

So, we ask a question whenever we build automations for clients. What happens when Bill leaves?

Most people hope his knowledge stays behind. In practice, it scatters. It sits in old emails. It hides in private notes. It lives in a few documents that no one can find when they need them. Some of it never gets written down at all. When Bill walks out the door, the company loses more than a person. It loses a memory.

The usual advice to prevent knowledge loss is to document everything. Write job aids. Write guides. Record videos. These things help, but only when people use them. A long document is easy to skip. A video without the right setup can confuse more than it helps.

There are simpler ways to keep Bill’s knowledge alive. None of them are flashy. None of them are groundbreaking. They work because they are grounded in how people actually work.

Contextual tooltips and cheatsheets

When we build web applications, we add tooltips that hold the information Bill knows. They sit right next to the field or button where someone might get stuck. If a user needs more detail, the tooltip links to a longer explanation.

In spreadsheets we automate, we add cheatsheets inside the workbook. Sometimes they sit in a side panel. Sometimes they appear in a custom ribbon. They give short reminders that help people move forward without digging through a separate document.

We used this approach for an estate planning spreadsheet for a wealth advisory firm.

Advisors needed to walk clients through complex scenarios. The cheatsheets gave them the small nudges they needed at the exact moment they needed them.

Centralized and categorized conversations

In a job management tool we built, our notes section served a purpose because notes without structure turn into a pile of text that no one wants to read.

We required every note to have a category. Clarification. Blocker. Update. Decision. We also required each note to be assigned to the person who needed to act on it.

This simple structure moved conversations out of inboxes and chat threads.

It turned scattered insights into a clear record. When someone new joins the team, they can see the history of a job without searching through old messages.

Knowledge must come before AI

Some people believe AI can solve every business problem. AI can help, but it cannot guess what Bill knows. His knowledge has to be captured in a meaningful way before any digital version of him can exist.

And for companies that do not want to attempt recording every keystroke, which has been a topic of discussion after reports about Meta exploring that kind of monitoring, these grounded approaches are a safer and more practical path.

Why Biill?

One of our team members once worked at a company where Bill really did leave. The fallout was rough. Processes stalled. Clients waited. No one knew how to fill the gaps. That experience shaped how we think about knowledge loss today.

When Bill leaves, the company should not lose its memory

With simple, thoughtful systems, it will not

LET'S BUILD YOURS

Where accuracy matters most
that's where we work

We work anywhere documents carry risk, financial impact, or compliance requirements.

What you're probably
wondering

Quick answers to the most common questions

What happens when critical company knowledge lives with one employee?

When key knowledge lives with one person, it often disappears when that person leaves. Important context ends up trapped in inboxes, private notes, spreadsheets, and memory, leaving teams to recreate decisions and slow operations after the fact.

Why isn’t documentation alone enough to prevent knowledge loss?

Documentation helps, but it often goes unused or out of date. Knowledge is retained more effectively when it appears directly inside the tools people use, at the moment they need it, rather than buried in long guides or inbox threads.

Can AI solve knowledge loss when employees leave?

AI can only work with knowledge that has already been captured. If critical context lives in emails or individual experience, AI cannot recreate it, which is why structured systems are required before automation or AI can help.

VIEW ALL QUESTIONS

Next Entries »