DEV Community: Dotnet Report

Build vs Buy: The Real Cost of Adding Reports to Your .NET SaaS Product

Dotnet Report — Sat, 04 Apr 2026 04:33:46 +0000

Every .NET SaaS team hits this moment: customers start asking for reports and dashboards. Do you build it yourself or use an embedded reporting solution?

The "build it" answer feels right at first. You know SQL, you know your data model, you have a charting library picked out. But there's a pattern I've seen repeatedly: teams underestimate the ongoing maintenance cost and end up with a reporting system that consumes 20–30% of a developer's time indefinitely.

What You're Actually Building

A production reporting system for a multi-tenant SaaS requires:

Query engine — filter, sort, group, aggregate
Multi-tenant data isolation — tenant-scoped at the query layer (not just UI)
Chart rendering + configuration UI
Dashboard layout engine (if you want multi-widget dashboards)
Saved report persistence + permissions
PDF/Excel export
Scheduled email delivery

Year 1 estimate for a custom build: 460–780 developer hours (~$57,500–$97,500 at market rates). That's before self-service report creation — if customers want to define their own reports, add 200–400 more hours.

Year 2+: ~20% of a senior developer's time for maintenance, new reports, schema migrations. That's $40,000–$60,000/year ongoing.

The Opportunity Cost

Every sprint spent on reporting infrastructure is a sprint not spent on your core product. Reporting is table stakes — customers expect it, but it's not what differentiates your SaaS.

When to Buy

For most .NET SaaS products: buying an embedded reporting solution is the right call. Dotnet Report ships as a NuGet package with the full stack included — report builder, dashboards, charts, scheduling, export, multi-tenant isolation. Integration takes 1–2 weeks. Ongoing maintenance is minimal.

The math: custom build saves you the license cost but costs you 460+ hours in Year 1 and $40K+ every year after. The break-even is usually never — especially when you factor in opportunity cost.

When to Build

Building makes sense if:

Reporting IS your core product (you're a BI/analytics SaaS)
You have highly specific domain requirements no commercial solution fits
You have dedicated reporting engineers with specialized domain expertise

For everyone else: the buy case is strong.

Full cost breakdown with tables: dotnetreport.com/blogs/build-vs-buy-reporting-net-saas/

Dotnet Report vs. Telerik Reporting: Which Is Right for Your .NET SaaS?

Dotnet Report — Sat, 04 Apr 2026 03:13:09 +0000

If you're evaluating embedded reporting for a .NET SaaS application, Telerik Reporting and Dotnet Report will both appear on your list. They're both mature, .NET-native products — but they're designed around fundamentally different workflows.

The Core Difference

Telerik Reporting is designed for developer-authored report delivery. A developer or report author uses the Telerik Visual Studio designer to create report definitions. Those reports are then delivered to end users who can view and filter them. Users can't build reports from scratch without designer access.

Dotnet Report is designed for user self-service. You expose your data model to Dotnet Report's engine, and your customers use a drag-and-drop builder to create their own reports — choosing columns, setting filters, picking chart types. Developer involvement per report drops to near zero after initial setup.

Multi-Tenant Isolation: The Key Difference for SaaS

Telerik doesn't have built-in multi-tenant isolation. If you serve multiple clients from a shared database, you implement tenant scoping yourself in every report definition. That works but creates maintenance risk — one missed filter can expose one client's data to another.

Dotnet Report enforces isolation at the query layer via a GetCurrentUser endpoint you implement:

[HttpGet("getCurrentUser")]
[Authorize]
public IActionResult GetCurrentUser()
{
    return Ok(new {
        clientId = User.FindFirst("tenant_id")?.Value,
        dataFilters = new[] {
            new { Field = "TenantId", Value = User.FindFirst("tenant_id")?.Value }
        },
        allowedTables = new[] { "Orders", "Customers", "Products" }
    });
}

These filters are applied server-side before any SQL executes. Users cannot override them in the report builder — they're enforced at the query layer, not the UI layer.

Pricing Model Comparison

Telerik Reporting: Per developer per year (~$1,500-$2,000+ per seat as part of DevCraft Complete). Cost rises with team size.

Dotnet Report: Fixed subscription regardless of the number of developers, end users, or tenants. Predictable and flat as you scale.

For SaaS economics, the distinction matters: as you add more customers and grow your team, Telerik costs scale up with headcount. Dotnet Report stays flat.

User Self-Service

Telerik: Provides a Web Report Designer for power users and report authors to create/edit reports in a browser. For non-technical end users who need to build reports from scratch, the UX requires training.

Dotnet Report: The drag-and-drop report builder is designed for non-technical business users. Finance managers, ops leads, customer success teams can build their own reports without SQL knowledge or training. Comparable in difficulty to building a pivot table in Excel.

Full Feature Comparison

Feature	Dotnet Report	Telerik Reporting
User self-service builder	Full drag-and-drop	Limited (power user designer)
Multi-tenant isolation	Built-in at query layer	DIY implementation
Pricing model	Fixed subscription	Per developer per year
Open-source front-end	Yes (MIT license)	No (proprietary viewers)
White-label branding	Full control	CSS theming only
Report scheduling	Built-in, user-configurable	Requires Reporting Server add-on
Dashboard builder	Included	Limited
Pixel-perfect print reports	Operational focus	Strong
Non-relational data sources	Relational only	JSON, CSV, web service, etc.

When to Choose Telerik

You need pixel-perfect, print-layout reports (invoices, regulatory documents)
A dedicated report author creates and maintains all report definitions
You already have Telerik DevCraft licenses
Reporting consumers are internal users, not SaaS customers

When to Choose Dotnet Report

Your customers need self-service (they build their own reports without developer involvement)
Multi-tenant data isolation needs to be bulletproof and enforced at the query layer
You want flat pricing that doesn't scale with developer headcount or tenant count
You need full white-label control (the Angular front-end is open-source)

Full comparison: dotnetreport.com/blogs/dotnet-report-vs-telerik-reporting/

Start a free 30-day trial of Dotnet Report — no credit card required.

Angular Reporting with a .NET Backend: What Actually Works in 2026

Dotnet Report — Sat, 04 Apr 2026 03:04:57 +0000

Adding reporting to an Angular + ASP.NET Core app sounds straightforward. You have SQL, Angular, and Chart.js. How hard can it be?

Harder than it looks, especially for multi-tenant SaaS.

The Core Challenges

CORS and auth passthrough. Your Angular app needs to call your ASP.NET Core API to fetch report data. That API needs to know who the current user is (for tenant isolation) and what they're allowed to see. JWT tokens, CORS headers, and security policies all add complexity before you write a single line of report logic.

Multi-tenant data isolation. This is where teams most often introduce bugs. The rule: tenant filtering must happen server-side in your ASP.NET Core API, never in the Angular component. A user could modify Angular component state. They can't modify your server-side WHERE clause.

Chart rendering across frameworks. Angular has great charting libraries (ng2-charts, Highcharts, ECharts). But integrating them with dynamic, user-defined report configurations — where the chart type, X axis, and grouping are all user-controlled — requires significant glue code.

The Architecture That Works

// Angular service to fetch report data
@Injectable({ providedIn: 'root' })
export class ReportService {
  constructor(private http: HttpClient) {}

  runReport(config: ReportConfig): Observable<ReportResult> {
    return this.http.post<ReportResult>('/api/reports/run', config);
  }
}

// ASP.NET Core: always enforce tenant isolation server-side
[HttpPost("run")]
public async Task<IActionResult> RunReport([FromBody] ReportConfig config)
{
    var tenantId = _userContext.GetTenantId(User);
    config.DataFilters.Add(new Filter { Field = "TenantId", Value = tenantId.ToString() });
    var result = await _reportEngine.Execute(config);
    return Ok(result);
}

Evaluation Criteria for Angular Reporting Solutions

When evaluating reporting tools for an Angular + .NET stack, prioritize:

Native Angular component — not an iframe or server-rendered widget
Server-side tenant enforcement — the tool must enforce data isolation at the query layer, not just the UI
Dynamic report configuration — users should be able to define columns, filters, and chart type without developer involvement
JWT / auth integration — passes through your existing auth context
Export to PDF/Excel — table stakes for business users
Scheduling — automated report delivery via email

Top Options for Angular + .NET Reporting in 2026

1. Dotnet Report — Best for Multi-Tenant SaaS

Dotnet Report ships an open-source Angular component (MIT license) that integrates with your ASP.NET Core API. You implement a GetCurrentUser endpoint that returns tenant context — the reporting engine applies it as a mandatory WHERE filter on every query.

What you get:

Drag-and-drop report builder in Angular (open-source, customizable)
SQL Server, MySQL, PostgreSQL support
Multi-tenant enforcement via GetCurrentUser endpoint
PDF, Excel, CSV export
Report scheduling with email delivery
Dashboard builder with user-defined KPI widgets
Fixed subscription pricing (no per-user fees)

Integration: 1-2 weeks for a typical ASP.NET Core app.

2. Telerik Reporting

Telerik's Angular Report Viewer component wraps server-side generated reports. The reports themselves must be authored in Telerik's designer — end users can view and filter, but can't build new reports. Good for developer-designed report delivery; not for self-service.

3. DevExpress Web Report Viewer

Similar to Telerik: Angular wrapper for server-rendered reports. Strong designer tooling, developer-oriented workflow. Per-developer licensing model that scales poorly for SaaS products serving many tenants.

4. AG Grid + Custom Build

AG Grid handles tabular display very well. Combined with a custom query builder and charting library, you can assemble a reporting solution — but expect 460-780 hours to build the full stack (query engine, multi-tenant enforcement, export, scheduling, saved reports). Only makes sense if reporting is your core product.

Multi-Tenant Enforcement Pattern (Critical)

This is the pattern most teams get wrong. Here is the correct implementation:

The key: dataFilters are applied server-side before any SQL executes. Users can add additional filters in the Angular report builder, but they cannot remove or override the tenant filter. This is what makes the isolation production-safe.

Comparison Table

Feature	Dotnet Report	Telerik	DevExpress	Custom Build
Angular component	Open-source	Viewer only	Viewer only	Build it
User self-service	Full builder	View only	View only	Build it
Multi-tenant enforcement	Built-in	DIY	DIY	Build it
PDF / Excel export	Yes	Yes	Yes	Build it
Scheduling	Yes	Yes	Yes	Build it
Pricing model	Fixed subscription	Per developer	Per developer	Developer time
Time to integrate	1-2 weeks	2-4 weeks	2-4 weeks	460-780 hours

Final Thoughts

Reporting in an Angular + .NET app is solvable, but the multi-tenant data isolation piece is where most teams introduce risk. Get that wrong and you have a security incident, not a reporting feature.

If you are building a SaaS product where reporting is a customer-facing feature, the build-vs-buy math strongly favors using an embedded reporting package. The 1-2 week integration cost vs. 460-780 hours to build the full stack is a significant difference in calendar time and engineering resources.

Full guide with integration walkthrough: https://dotnetreport.com/blogs/angular-reporting-dotnet-backend-2026/

Start a free 30-day trial: https://dotnetreport.com

Build vs Buy: The Real Cost of Adding Reports to Your .NET SaaS Product

Dotnet Report — Fri, 03 Apr 2026 03:06:50 +0000

Every .NET SaaS team hits this moment: customers start asking for reports and dashboards. Do you build it yourself or use an embedded reporting solution?

What You're Actually Building

A production reporting system for a multi-tenant SaaS requires:

Query engine — filter, sort, group, aggregate
Multi-tenant data isolation — tenant-scoped at the query layer (not just UI)
Chart rendering + configuration UI
Dashboard layout engine (if you want multi-widget dashboards)
Saved report persistence + permissions
PDF/Excel export
Scheduled email delivery

Year 1 estimate for a custom build: 460–780 developer hours (~$57,500–$97,500 at market rates).

Year 2+: ~20% of a senior developer's time for maintenance. That's $40,000–$60,000/year ongoing.

The Opportunity Cost

Every sprint spent on reporting infrastructure is a sprint not spent on your core product.

When to Buy

When to Build

Building makes sense if:

Reporting IS your core product
You have highly specific domain requirements no commercial solution fits
You have dedicated reporting engineers

For everyone else: the buy case is strong.

Full cost breakdown: dotnetreport.com/blogs/build-vs-buy-reporting-net-saas/

Row-Level Security in Embedded Reporting: The Patterns That Actually Work for .NET SaaS

Dotnet Report — Wed, 01 Apr 2026 05:27:21 +0000

When you add embedded reporting to a multi-tenant SaaS product, row-level security isn't optional — it's the whole ballgame. One misconfigured RLS policy and you're serving Tenant A's data to Tenant B. In a B2B context, that's a trust violation that ends customer relationships.

Here's a practical breakdown of RLS patterns for embedded reporting in ASP.NET Core, including the vulnerability that catches most teams.

The Critical Rule

Tenant ID must come from the server-side authenticated session. Always.

This pattern is wrong:

// DON'T DO THIS
reportTool.init({
    tenantId: document.getElementById('tenantId').value
});

A malicious user changes that value. You have a cross-tenant data breach.

This pattern is correct:

// Server-side — user cannot tamper with this
public override Task<DotNetReportUser> GetCurrentUser()
{
    return Task.FromResult(new DotNetReportUser
    {
        ClientId = HttpContext.User.FindFirstValue("TenantId"),
        IsAdmin = User.IsInRole("ReportAdmin")
    });
}

Two Layers of RLS

Effective RLS in reporting requires:

Layer 1: Tenant isolation — Company A never sees Company B's data, even a single row, even in aggregates.

Layer 2: User-level scoping — Within Tenant A, a regional manager only sees their region's records.

Most implementations get Layer 1 right but skip Layer 2 for "later." Later often doesn't come until a customer notices a regional manager can see another region's data.

Defense in Depth with SQL Server RLS

Application-layer RLS is necessary but not sufficient. Add SQL Server's native Row-Level Security as a backstop:

CREATE FUNCTION dbo.fn_tenantPredicate(@TenantId INT)
RETURNS TABLE WITH SCHEMABINDING AS
RETURN SELECT 1 AS result
    WHERE @TenantId = CAST(SESSION_CONTEXT(N'TenantId') AS INT);

CREATE SECURITY POLICY dbo.TenantPolicy
    ADD FILTER PREDICATE dbo.fn_tenantPredicate(TenantId) ON dbo.Orders
WITH (STATE = ON);

Set the session context in an EF Core interceptor:

public class TenantRlsInterceptor : DbCommandInterceptor
{
    public override InterceptionResult<DbDataReader> ReaderExecuting(
        DbCommand command, CommandEventData eventData,
        InterceptionResult<DbDataReader> result)
    {
        SetTenantContext(command.Connection);
        return base.ReaderExecuting(command, eventData, result);
    }

    private void SetTenantContext(DbConnection conn)
    {
        using var cmd = conn.CreateCommand();
        cmd.CommandText = "EXEC sp_set_session_context @key=N'TenantId', @value=@t";
        cmd.Parameters.Add(new SqlParameter("@t", _tenantService.GetCurrentTenantId()));
        cmd.ExecuteNonQuery();
    }
}

Test Your RLS

Write dedicated cross-tenant isolation tests — not just happy-path functional tests:

[Fact]
public async Task Report_ShouldNotReturnCrossTenantData()
{
    await SeedData("tenant-a", recordCount: 50);
    await SeedData("tenant-b", recordCount: 30);

    var user = CreateTestUser(tenantId: "tenant-a");
    var results = await _reportService.RunReportAsync(testReportId, user);

    // Must only return tenant-a's records
    Assert.All(results, row => Assert.Equal("tenant-a", row["TenantId"]));
    Assert.Equal(50, results.Count);
}

The Full Writeup

This is a condensed version — the full article covers user-level scoping patterns, the common RLS vulnerabilities (cached results without tenant keys, inconsistent table coverage, aggregate leakage), and a complete comparison table of approaches:

👉 https://dotnetreport.com/blogs/row-level-security-embedded-reporting-net/

Building embedded reporting into a .NET SaaS product? Happy to answer questions in the comments.

Built with Dotnet Report — embedded self-service reporting for multi-tenant ASP.NET Core applications.