I built a real quote system with .NET 10 and Blazor Server — and this is what I learned

A few weeks ago, I started a personal project with a simple goal: to automate the quoting process of a glassworks company that, until then, had been preparing each budget by hand. Repeated calculations, different formats each time, zero ordered history. It ended up being much more than I initially imagined: a complete budget management system, with a product catalog, multiple prices per supplier, margin calculation, export to PDF with the actual format already used by the business, and deployment as a service on a local network.

Stack: .NET 10 + Blazor Server — server-rendered interactivity, without the need for a separate API

Entity Framework Core + SQLite

MudBlazor for the interface

QuestPDF for generating the final document

It wasn't a tutorial followed to the letter. It was about solving a real problem at a time. Here are three moments that I thought were interesting to share.

Thinking well about deletion rules, not just the model

When modeling relationships in Entity Framework Core, it's easy to focus only on which field references which other, and leave OnDelete in its default behavior. But each relationship has a business question behind it: what has to happen if I delete this?

In this project, a Client with associated budgets cannot be deleted — we have to avoid losing commercial history by accident. On the other hand, an ItemPresupuesto doesn't make sense to exist without its parent Presupuesto, so if the budget is deleted, its items go with it.

Block 1 — Relationships and deletion rules (VidrieriaContext.cs)

entity.HasOne(p => p.Cliente)

.WithMany(c => c.Presupuestos)

.HasForeignKey(p => p.ClienteId)

.OnDelete(DeleteBehavior.Restrict);

entity.HasOne(p => p.Cotizador)

.WithMany()

.HasForeignKey(p => p.CotizadorId)

.OnDelete(DeleteBehavior.Restrict);

entity.HasOne(i => i.Presupuesto)

.WithMany(p => p.Items)

.HasForeignKey(i => i.PresupuestoId)

.OnDelete(DeleteBehavior.Cascade);

Same tool (OnDelete), two opposite decisions — and both correct, depending on what each relationship represents in the business.

A catalog selector that scales without becoming illegible

The system has categories with subcategories, products within each one, and each product with several reference prices depending on the supplier. With few loaded data, a simple tree works well — but as the catalog grows, navigating by force of clicks becomes tedious and increases the risk of choosing the wrong item.

The solution was a component with a search that filters the entire tree in memory and auto-expands the branches that match:

Block 2 — Recursive filtering (SelectorProductoCatalogo.razor)

private bool CategoriaVisible(Categoria categoria) =>

!HayBusqueda ||

CategoriaNombreCoincide(categoria) ||

productosPorCategoria[categoria.Id].Any(ProductoCoincide) ||

categoriasPorPadre[categoria.Id].Any(CategoriaVisible);

A category is visible if its name matches, if it has a product that matches, or if any of its subcategories is visible (recursively).

That's enough for the tree to be reduced to only the relevant branches when writing in the search — without touching the database on each keystroke, everything solved on data already loaded in memory with ILookup.

The bug that didn't throw any error

This was the most difficult to diagnose. A button stopped responding — without exceptions, without anything in the browser console, without anything on the server. The Blazor circuit was alive, other buttons worked.

The cause: some global components (notification and dialog providers) lived in the root layout of the application, outside the tree of any page with interactive render mode. They were rendered only once, in static mode, and never connected to the real circuit.

Block 3 — The fix of the render mode that left buttons "dead"

The lesson I take away: in Blazor Web App, the render mode is not inherited between "brother" components in the tree — it only propagates to the descendants of the one that declares it.

A small detail, but one that, without understanding it, can make you lose hours.

Closing

None of these problems appeared in a tutorial. They appeared using the real system, with real data, with a real user giving me feedback.

That was the most valuable part of the project: not just writing code that works, but understanding why something didn't work before fixing it.

If you're interested in the architecture, some specific technical detail, or just want to chat about the project, comments are open.