Most ISV product teams I talk to have filed Microsoft Fabric apps under "marketplace strategy," somewhere between the AppSource listing and the Teams app nobody maintains. That is the wrong mental model, and it will cost some of them their category.
A workload built with the Fabric Workload Dev Kit is not an add-in bolted to the side of Fabric. It is a native surface that renders beside Lakehouse, Power BI, and Data Factory, inside the tool where the buyer's data team already spends its day. That makes this a distribution decision, and distribution decisions with a lock-in risk attached deserve a real evaluation, not a wait-and-see posture. Here is the framework to make that call in 90 days.
What a Fabric app actually is (and is not)
The Fabric Workload Development Kit, which went generally available at Ignite 2024, lets you register your own item types in a Fabric tenant. Your workload gets a real presence: items that live in workspaces, a UI that renders inside the Fabric shell, read and write access to OneLake, and authentication that flows through Microsoft Entra ID using on-behalf-of tokens, so your app acts as the signed-in user, not a service account with god rights.
Be precise about what is automatic and what is not. Discovery through the Workload Hub and rendering in the Fabric shell come with the platform. Entra identity flow, item lifecycle handling, and governance behavior for your custom items are things you implement against the dev kit's contracts. And your backend runs on your own infrastructure. Fabric brokers requests to you; it does not host your compute.
This is a different animal from everything ISVs have shipped into the Microsoft ecosystem before. A Power BI custom visual is a rendering component. A Teams app is a collaboration surface. An Azure Marketplace SaaS listing is a commerce contract with zero data-plane coupling. A Fabric workload sits in the data plane itself, next to the customer's tables.
One clarification the "app store" framing blurs: the Workload Hub handles in-product discovery and deployment. Procurement and monetization still run through your own commercial motion or an Azure Marketplace transaction. Fabric solves the "get in front of the buyer inside their tool" problem, not the "collect the check" problem.
The docs undersell the engineering
The Workload Dev Kit documentation makes registration look like a configuration exercise. In practice, the frontend/backend contract, item CRUD lifecycle, and job scheduling integration take real engineering time, and the sample workload only covers the happy path. Budget for a proper build, not a hackathon. This is judgment from reading the contracts closely, not a measured estimate; your team's number will vary.
The takeaway: this is platform-native software. Evaluate it like a platform bet, with platform-bet diligence, not like another listing to keep fresh.
The distribution math behind Microsoft Fabric apps
Enterprise SaaS deals die in two places: procurement and security review. Every data vendor selling into the enterprise knows the ritual. Vendor security questionnaires, data residency reviews, a new DPA, a network architecture diagram for where the customer's data will live.
Now walk through what a Fabric-native workload changes structurally. The customer's data does not leave their tenant; your workload operates on OneLake data under their existing workspace roles and sensitivity labels. Identity is their Entra ID. The platform relationship already exists under their Microsoft agreement. I will not attach a percentage to how much friction that removes, because nobody has published one and I refuse to invent it. But the logic is hard to argue with: every control the customer already trusts is one review you do not restart from zero. Some reviews remain, because your backend is still your backend, but the surface area shrinks.
Then there is the crowding question. Microsoft said at Build 2024 that more than 11,000 organizations use Fabric, and the number has grown since. Meanwhile the Workload Hub is thin. Microsoft's own Ignite 2024 announcement named a handful of launch partners, including Esri, SAS, Informatica, and Teradata. That is a short list for a platform with that customer base. Compare it to AppSource on day one versus AppSource today.
I will take the strong position: for data-adjacent ISVs, this is the cheapest enterprise distribution channel Microsoft has offered since AppSource launched. Early entrants get category positioning while the hub has a dozen tiles instead of a thousand. That window closes the way it always does, quietly and then all at once.
The OneLake trade: interoperability story, capacity-model reality
Here is where the cheerleading stops, because the trade has real teeth.
The good half first. Building Fabric-native means your data model lives in Delta Lake tables on OneLake, open Parquet under the hood. That is a genuinely strong OneLake ISV integration story: the customer keeps one copy of their data, in an open format, readable by every engine in their estate and by yours. No proprietary storage tier, no export pipeline, no "your data is in our cloud now" conversation. For customers burned by data silos, this is the single best sales argument a Fabric workload has. I have written before about how OneLake shortcuts change data architecture, and the same zero-copy logic works in the ISV's favor.
Now the cage. Your cost of goods becomes entangled with Microsoft's capacity unit model. Fabric compute is billed in CUs across F SKUs; published list pricing puts an F64 at roughly $11.52 per hour pay-as-you-go, region dependent, per the Azure Fabric pricing page, with reservations meaningfully cheaper. Those are Microsoft's prices to change, and Microsoft's smoothing and throttling behavior to define. If your margin model assumed compute costs you control on infrastructure you tune, you just gave away a lever.
The second risk is sharper: Microsoft ships first-party workloads aggressively. If your feature is adjacent to something on the Fabric roadmap, you can be commoditized in a single release wave. Ingestion, transformation, and basic BI are already spoken for. Your IP survives only if it lives above the storage substrate: domain logic, vertical data models, proprietary ML, regulated workflows Microsoft will not build.
Prototype CU behavior before you price anything
CU consumption under real customer load is hard to predict from documentation alone. Background jobs, smoothing windows, and interactive spikes behave differently than the pricing table implies. Run a representative workload against a trial capacity and measure before you commit to a pricing model. Any modeling you do before that is illustrative; calibrate against actuals.
The takeaway: name the cage risk in your board deck, in the same slide as the distribution upside. Not after you have signed customers.
Who should build Microsoft Fabric custom workloads
Fit is not about whether your team can technically build against the dev kit. Almost any competent platform team can. Fit is about where your product's gravity lives: if your value compounds by sitting next to the customer's OneLake data, the channel works for you; if it does not, you are renting expensive real estate in someone else's mall.
| Signal | Strong fit: build | Weak fit: skip |
|---|---|---|
| Product gravity | Value increases next to customer data: observability, data quality, MDM, industry analytics | Value is independent of where the data sits |
| Buyer base | Data teams already living in the Microsoft stack | Multi-cloud-neutral buyers, or a promise of cloud neutrality you cannot break |
| Compute economics | Analytics-shaped workloads that map to CU consumption | GPU-heavy, custom silicon, or margin models that need infrastructure control |
| Latency profile | Batch and interactive analytics | Sub-second transactional paths where Delta and Parquet fight you |
| IP position | Domain logic and models above the storage layer | Features adjacent to ingestion, transformation, or basic BI |
| Roadmap exposure | Vertical or regulated capability Microsoft is unlikely to build | Horizontal feature one Fabric release away from first-party |
Strong-fit categories are the ones the launch partner list already hints at: observability over the data estate, data quality and master data management, geospatial and industry analytics. Anything where the pitch is "we do more because we can see your actual tables, governed, in place."
Weak fit is just as clear. Transactional cores, sub-second serving, GPU-heavy inference where Fabric's compute model does not match your economics, and any product whose buyers are not Microsoft-centric.
Here is my opinionated heuristic, explicitly a rule of thumb and not a measured threshold: if fewer than roughly a third of your sales pipeline runs on the Microsoft data stack, skip Fabric-native for now and revisit in a year. Below that line, the workload becomes a side bet your roadmap subsidizes, and side bets on platform channels rot fast.
Where your product's gravity lives decides this. Not what your engineers can build.
The AI angle Microsoft is underselling
Everything above treats the buyer as a human opening a workload in a browser. That framing is already aging.
Because Fabric workloads operate on governed Delta tables in OneLake, they are addressable by the AI experiences Microsoft is building over the tenant's estate. Copilot in Fabric and Fabric data agents reason over exactly the data layer a native workload plugs into, no custom connectors, no separate semantic export. Verify the preview versus GA status of specific agent features before you build against them; they move quarterly.
Here is the forward-looking argument, and I label it as such because nobody can cite the future: the long-term prize is being the workload an agent calls, not the dashboard a human opens. App-store dynamics repeat with a new user. When an agent orchestrating over a tenant's data estate needs a data quality score, an entity resolution, or a vertical risk model, it will call whatever capability is registered, governed, and adjacent to the data. Workloads outside the estate do not get the call.
Do not build against specific agent APIs today; treat them as unstable. Build the durable position instead: your data in open Delta format, your operations exposed as governed items, your value legible to whatever orchestrates over the estate next.
Position your workload as agent-ready data plus actions, and you are early to the next distribution shift instead of reacting to it.
The 90-day evaluation framework
One engineer-quarter buys you an evidence-based decision. Being late to a platform channel costs a market position. That is the whole cost-benefit.
Define the kill criteria before day one, in writing: the bet dies if CU economics break your margin model, or if your buyers are demonstrably not in Fabric. Everything else is noise.
- Days 1 to 30: prototype against the dev kit Build a thin vertical slice with the Fabric Workload Dev Kit: one item type, real Entra on-behalf-of auth, real OneLake reads and writes against a sample workload. The goal is not a demo. The goal is to surface the frontend/backend contract work and lifecycle handling the docs gloss over, so your effort estimate is grounded in your codebase, not Microsoft's sample.
- Days 31 to 60: model CU economics against your current spend Run representative load on a trial capacity and measure CU consumption, then model customer-scale costs using published Fabric list pricing. Treat every number as illustrative until you have actuals; industry-standard inputs are a starting point, and your workload shape will move the answer. Compare the result against your current cloud COGS and your pricing floor.
- Days 61 to 90: pressure-test with three design partners Take the prototype to three customers or prospects who run Fabric today. Ask two questions: would they deploy your workload inside their tenant instead of your SaaS, and does inherited governance actually shorten their review process for a vendor like you. Their answers tell you whether Fabric-native is a channel or a cage for your product specifically.
For the cost-modeling leg, I have covered modeling Fabric capacity costs in more depth, including where smoothing and background jobs distort naive per-hour math.
A 90-day timebox is cheap insurance. Skipping the timebox is the expensive option, whichever way the decision goes.
Decide on Microsoft Fabric apps this quarter
Build if your product's gravity is in the customer's data estate, where governed adjacency to OneLake makes your product better and the Workload Hub is still thin enough to own a category tile. Skip loudly if it is not, and put the revisit date in the calendar rather than letting the default decide for you.
Microsoft Fabric apps are a channel or a cage, and for your product they are exactly one of the two. You can find out which one in 90 days. The vendors who treat that as optional will find out from their competitors' launch posts instead.
This article was originally published at az365.ai. I'm Alex Pechenizkiy, an Azure and Power Platform solutions architect writing honest, vendor-neutral analysis of the Microsoft AI stack. More at az365.ai.
Top comments (0)