AI Built the App: Microsoft Fabric Made It Possible; Rayfin Taught Us About Performance

Lessons from Turning a Claude-Generated Prototype into a Production-Ready Microsoft Fabric Application

When I first used Claude to generate the initial version of a client intelligence application, I was surprised by how much it could produce in such a short time.

Within hours, we had a functional application that could:

The application was built using Rayfin on Microsoft Fabric, and the result looked impressive. The UI and UX were far beyond what most people associate with traditional analytics solutions.

Yet the most valuable lesson wasn't how quickly AI generated the application.

It was what happened after the application started handling real workloads.

Rayfin + Microsoft Fabric: Beyond Traditional BI

One of Rayfin's biggest strengths is flexibility.

Unlike traditional BI tools that constrain developers to predefined layouts and visual interactions, Rayfin provides a React-based canvas where developers can create experiences that feel more like modern SaaS applications than dashboards.

This allows teams to build:

Combined with Microsoft Fabric's semantic models, developers can expose enterprise-grade analytics through application experiences that users genuinely enjoy interacting with.

The trade-off is important.

Power comes with responsibility.

The Difference Between Power BI and Rayfin

Power BI is fundamentally a BI platform.

Rayfin is fundamentally an application platform.

That distinction changes everything.

Power BI automatically handles many decisions most developers never think about:

Power BI Typically Handles Developers Rarely Worry About
Visual-level execution Query orchestration
Independent visual refresh Dependency management
Parallel rendering Concurrency planning
Semantic model optimization Request volume management
Progressive visual loading Performance architecture

When building applications with Rayfin, these decisions become the developer's responsibility.

The platform gives you complete freedom.

It also gives you complete ownership of performance.

What AI Got Right

Claude generated a surprisingly solid foundation.

The initial solution included:

The application worked.

The user experience was good.

The code was maintainable.

Most importantly, stakeholders could immediately start providing feedback instead of waiting for months of development.

This is where AI truly shines.

It eliminates the blank-page problem.

The Performance Illusion

Many AI-generated applications share a similar characteristic:

They feel fast during development.

Why?

Because development environments typically involve:

Once an application reaches real-world usage, performance characteristics begin to change.

The challenge is rarely correctness.

The challenge is architecture.

How the Architecture Evolved

Version Query Strategy Approx. Queries Parallelism Level
Claude Generated Prototype Large combined queries ~7 Page-level
Optimized Production Design Smarter filtering + targeted queries ~9 Page-level + component-level
Full Parallel Experiment Independent KPI execution ~23 Maximum parallelism

At first glance, increasing query count appears counterintuitive.

However, performance is often determined by how work is distributed, not simply how many requests are executed.

Three Ways To Build The Same Experience

Approach 1: Sequential Thinking

1    Load Customer
          ↓
2    Load Revenue
          ↓
3    Load Pipeline
          ↓
4    Load Support
          ↓
5    Load Customer Feedback

Advantages:

Disadvantages:

Approach 2: Power BI Thinking

Customer Summary     |||
Revenue KPIs         |||
Pipeline KPIs        |||
Support KPIs         |||
Customer Voice       |||

Everything begins simultaneously.

The page completes when the slowest component finishes.

This is one of the key reasons Power BI reports often feel surprisingly responsive.

Approach 3: Full Metric Parallelism

Revenue KPI          |||
Growth KPI           |||
Pipeline KPI         |||
Support KPI          |||
Renewal KPI          |||
Sentiment KPI        |||

Every KPI becomes an independent workload.

This maximizes concurrency but also increases backend activity.

The fastest technical architecture is not always the best business architecture.

Why Power BI Cards Are One of the Most Underrated Performance Features

One of the most interesting lessons from this project was gaining a new appreciation for Power BI Cards.

Most people think of a card as a simple KPI display.

From a performance engineering perspective, it is much more than that.

A Card Represents an Independent Compute Unit

Consider the following metrics:

KPI Business Question
Revenue How much revenue exists?
Pipeline What opportunities are open?
Support How healthy is customer support activity?
Customer Health What is the overall relationship quality?

Each KPI can be calculated independently.

That independence enables concurrency.

Why Parallel Cards Matter

Imagine four calculations that each require one second.

Design Total Wait Time
Sequential Execution ~4 seconds
Parallel Execution ~1 second

The amount of work is identical.

The execution strategy is different.

This is where Power BI quietly delivers value.

A dashboard full of cards isn't just displaying information.

It's encouraging an architecture built around independent, parallel computations.

Generic DAX Patterns: Correct vs Efficient

AI naturally generated patterns optimized for simplicity.

Combined Query Pattern

EVALUATE
SUMMARIZECOLUMNS(
    "Metric A", [Metric A],
    "Metric B", [Metric B],
    "Metric C", [Metric C]
)

Benefits:

Limitations:

Independent KPI Pattern

CALCULATE(
    [Metric A],
    CurrentBusinessContext
)

Benefits:

The goal was not to rewrite business logic.

The goal was to teach the application how to retrieve information more intelligently.

Performance Results

Architecture Relative Response Time Relative Complexity
Initial AI-generated version Baseline Low
Optimized architecture ~75% improvement Medium
Full parallel experiment Similar user experience Higher

One of the most surprising findings was that the majority of performance gains came from:

Not from additional computing power.

The Hidden Cost of Unlimited Parallelism

Metric Optimized Design Full Parallel Design
User Experience Excellent Excellent
Backend Requests Lower Higher
Operational Complexity Lower Higher
Scalability Risk Lower Higher
Production Recommendation ✅ Preferred ⚠ Use selectively

This was one of the biggest lessons from the exercise.

The most parallel architecture wasn't dramatically faster.

It simply consumed more resources.

Good engineering is often about finding the right balance.

What Engineering Added

Claude gave us the first draft.

Engineering transformed it into a production-ready solution.

The biggest improvements came from:

The code wasn't reinvented.

The architecture matured.

The Real Lesson for Fabric Developers

Microsoft Fabric gives developers tremendous flexibility.

Rayfin extends that flexibility by allowing teams to build experiences that feel like modern applications rather than dashboards.

But neither platform automatically solves performance.

That's still the responsibility of developers.

AI Excels At Developers Must Own
Rapid prototyping Query optimization
UI generation Performance engineering
Boilerplate code Scalability decisions
Workflow creation Architectural tradeoffs
Fast iteration Bottleneck analysis

AI generated the application.

Microsoft Fabric provided the analytics foundation.

Rayfin delivered the user experience.

The engineering challenge was teaching the application how to use those capabilities efficiently.

Beyond Microsoft Fabric: A Universal Engineering Lesson

Although this article uses Claude, Microsoft Fabric, and Rayfin as examples, the underlying engineering principles are universal.

Whether an application is generated using ChatGPT, Claude, Cursor, Replit, GitHub Copilot, Gemini, or future AI-assisted development platforms, the same engineering challenges remain.

Likewise, these principles are not limited to Microsoft Fabric, DAX, or Power BI semantic models. They apply equally to SQL, Spark, Python, C#, Java, JavaScript, REST APIs, and virtually every modern technology stack.

AI can rapidly generate working software, but it cannot infer the performance characteristics of your production environment. Decisions around workload orchestration, query optimization, concurrency, caching, context propagation, scalability, and efficient resource utilization remain engineering responsibilities.

The tools will continue to evolve.

The engineering principles do not.

Final Thoughts

This project changed how I think about AI-generated software.

The biggest breakthrough wasn't that Claude could build a working application.

The breakthrough was realizing how much value comes after the code is generated.

Rayfin and Microsoft Fabric make it possible to build experiences that go far beyond traditional BI.

But unlike Power BI, they don't automatically make performance decisions on your behalf.

They provide a blank canvas.

And with a blank canvas comes responsibility.

The future isn't AI replacing developers.

The future is AI accelerating development while engineers focus on architecture, performance, scalability, and the countless engineering decisions that transform working software into production-ready systems.

The technologies will evolve. Today's AI coding assistant may be replaced by another tomorrow, and today's programming language, query engine, or application framework may change. But the engineering principles of architecture, scalability, concurrency, and performance optimization remain timeless.

AI created the first draft. Microsoft Fabric powered the data. Rayfin delivered the experience. Engineering transformed it into a system that could perform at enterprise scale. The same lesson applies regardless of which AI, framework, database, or programming language you use.