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 , and the number has grown since. Meanwhile the Workload Hub is thin. Microsoft's own , 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 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 .
SOCIAL SHARE CARD GENERATOR