What a CRM source-code package contains
Indotalent’s Blazor CRM Source Code is a single-project .NET 10 application. The CRM feature set, its endpoints, its EF Core entities, and its Blazor screens ship together rather than being split into separate class-library projects. That structure makes the codebase easier to open, build, and read for a developer who wants to customize one workflow instead of first learning a large solution layout.
This evaluation describes the actual application folder by folder. It does not assume that every pattern found elsewhere in the codebase applies to the CRM scope. The companion article Building a CRM with ASP.NET Core covers the composition in more detail, while CRM Vertical Slice Architecture traces a single operation end to end.
Take the pipeline modules tour
The CRM screens are grouped under Features/Pipeline/. PipelinePage.razor is a tabbed shell that hosts the whole sales pipeline: Campaign, Budget, Expense, Leads, Lead Contacts, Lead Activities, Sales Team, and Sales Rep. Each module follows the same layout:
Features/Pipeline/Lead/
LeadService.cs
LeadEndpoint.cs
Components/
LeadPage.razor
_LeadCreateForm.razor
_LeadUpdateForm.razor
_LeadDataTable.razor
Cqrs/
CreateLeadHandler.cs
CreateLeadValidator.cs
UpdateLeadHandler.cs
GetLeadListHandler.cs
GetLeadByIdHandler.cs
GetLeadLookupHandler.cs
DeleteLeadByIdHandler.csCampaign, Budget, Expense, LeadContact, LeadActivity, SalesTeam, and SalesRepresentative repeat the same shape. Campaign additionally owns budget and expense child dialogs, and SalesTeam owns its representative list. Entities stay in Data/Entities/, so the UI folders remain focused on screens, services, endpoints, and CQRS handlers.
Recognize the shared stack
The project file targets net10.0 and references MudBlazor 9, MediatR, FluentValidation, RestSharp, ASP.NET Core Identity with JwtBearer, and EF Core with SQL Server, PostgreSQL, and MySQL provider packages. Program.cs registers four dependency groups: AddConfigBackEndDI for MediatR behaviors and validators, AddInfrastructureDI for database and authentication services, AddConfigFrontEndDI for the shared Blazor client plumbing, and AddFeaturesDI for the feature services.
The API group is mounted with app.MapGroup("/api") and an endpoint filter that fills the current user context from the authenticated request. Each pipeline feature maps its own route group under that root and requires an authenticated JWT bearer token. The Blazor Server UI authenticates with the Identity cookie and uses the same JWT for its REST calls through a shared BaseService that attaches the bearer token and handles expired-token refresh.
Check the database and demo data
Infrastructure/Database/ contains AppDbContext, per-entity IEntityTypeConfiguration classes under MsSQL/Configuration/, a seeder that runs at startup, and a folder of demo seeders for each entity including Campaign, Lead, LeadContact, LeadActivity, SalesTeam, SalesRepresentative, Budget, and Expense. The provider is chosen from DatabaseSettings: when a configured database is active, startup calls EnsureCreated and then seeds demo rows so the pipeline screens have data to display immediately.
Shared persistence behavior is centralized in AppDbContext. Audit fields and a soft-delete flag are applied to added and modified rows, deleted entities become IsDeleted = true updates, and an EF query filter excludes deleted rows from normal queries. Entities that implement the auto-number interface receive a document number on insert.
Follow the customization path
A typical change starts in the feature folder, not in a separate layer. To add a field to a lead, you update Data/Entities/Lead.cs, the matching LeadConfiguration length rule, the request and response DTOs inside Features/Pipeline/Lead/Cqrs/, the form component, and the data table. Because the handler, its DTOs, and its command record live in the same file, the contract change is easy to trace.
For a larger change such as a new pipeline stage, the enum lives in Data/Enums/, the lookup response exposes it to the form, and reports that group leads by stage read it from the database value. Extensions that touch shared behavior, such as the query filter or the response envelope, should be reviewed across all consumers before they are changed.
Review the complete application
Read the module that matters most to you first, then follow one workflow through its component, service, endpoint, handler, and database configuration. The C# business model guide explains the lead, contact, activity, campaign, and closing model behind the screens. Building a CRM with ASP.NET Core and CRM Vertical Slice Architecture then describe the hosting and request path in depth. See this architecture implemented in a complete Blazor CRM application.