Senior .NET 8 Full Stack Developer for Multi-Tenant Operations & Workflow Management Platform

We are looking for an experienced Full Stack .NET Developer to build Phase 1 of a multi-tenant operations and workflow management platform. The system will be used by multiple organizations to manage customers, projects, work orders, tasks, approvals, documents, internal activity and operational reporting from one central application. This is more than a basic CRUD dashboard. The application needs proper architecture, tenant-level data isolation, role-based access control, configurable workflows, audit logging, background processing, reporting and third-party API integration. We are looking for someone who is comfortable taking ownership of both backend and frontend development and can make sensible architectural decisions rather than simply implementing individual screens. The initial contract covers the production-ready MVP. Additional modules may be developed in later phases. Preferred technology stack Backend: - C# - .NET 8 - ASP.NET Core Web API - Entity Framework Core - SQL Server - ASP.NET Core Identity / JWT authentication - REST API architecture - Background workers or Hangfire - Redis where appropriate - Swagger / OpenAPI Frontend: - React - TypeScript - REST API integration - Responsive UI Infrastructure: - Microsoft Azure - Docker - Git / GitHub - CI/CD - Structured application logging Equivalent technologies can be suggested where there is a strong technical reason. Core application requirements 1. Multi-tenant architecture The application should support multiple organizations within the same platform. Each organization should have its own: - Users - Customers - Projects - Work orders - Tasks - Documents - Settings - Activity history - Reports Users from one organization must never be able to access another organization's data. We expect the developer to implement tenant-aware queries and a clean tenant isolation strategy rather than manually filtering data inside individual controllers. 2. Authentication and authorization The platform should have secure authentication and configurable access control. Initial user types will include: - System Administrator - Organization Administrator - Manager - Staff Member - Viewer We need permission-based authorization for sensitive operations. Examples: A Viewer may be able to view a project but not edit it. A Staff Member may update assigned tasks but not approve work orders. A Manager may approve workflow steps and access reports. An Organization Administrator may manage users and permissions within their organization. Authentication should use a secure ASP.NET Core approach such as Identity with JWT-based API authentication. 3. Customer management Each organization should be able to maintain its own customer records. Customer functionality should include: - Customer details - Contacts - Notes - Status - Associated projects - Attached documents - Search - Filtering - Activity history The application should maintain the relationship between customers and their projects, work orders and other operational records. 4. Project management Users should be able to create and manage projects linked to customers. A project may contain: - Basic project information - Assigned team members - Status - Priority - Start and due dates - Work orders - Tasks - Documents - Notes - Comments - Activity timeline Project lists should support pagination, sorting, filtering and search. 5. Work order management Projects should contain operational work orders. Each work order should support: - Assigned employee or team - Status - Priority - Due date - Description - Attachments - Comments - Tasks - Approval state - Activity history Users should be able to see which work orders require attention and which are waiting for approval. 6. Task management Tasks should be assignable to users and linked to projects or work orders. Functionality should include: - Task title and description - Assignment - Priority - Due date - Status - Comments - Attachments - Completion tracking The dashboard should make overdue and upcoming tasks easy to identify. 7. Workflow and approval engine One important part of the application is a configurable workflow system. Example workflow: Draft → Submitted → Under Review → Approved → Completed The architecture should allow different entities to follow different workflows later. The system should record: - Current workflow state - Previous state - User who changed the state - Timestamp - Comments or approval notes Certain workflow transitions should only be available to users with the required permission. For example, a Staff Member may submit a work order, but only a Manager can approve it. The workflow implementation should be structured so new states and transition rules can be added without rewriting the application. 8. Audit trail We need an audit log for important actions. The application should be able to record events such as: - Record creation - Record updates - Status changes - Workflow transitions - Approvals - User management changes - File uploads - Important administrative actions For relevant changes, the audit history should identify: - User - Action - Record - Date/time - Previous value where practical - New value where practical Users with permission should be able to view the audit history. 9. Document management Projects, customers and work orders should support document attachments. Required functionality: - Upload files - Download files - Associate files with specific records - Record uploader - Record upload date - Basic metadata - Delete or archive based on permissions The architecture should make it possible to move document storage to Azure Blob Storage. 10. Dashboard and reporting The application needs an operational dashboard. Initial dashboard information should include: - Active projects - Open work orders - Overdue tasks - Pending approvals - Recently completed items - Tasks by status - Work orders by status - Activity over a selected date range Reports should support filtering by: - Organization - Customer - Project - User - Status - Date range At least one report should support CSV or Excel export. 11. Background processing Some application operations should run asynchronously instead of blocking API requests. Examples include: - Reminder notifications - Scheduled reports - Overdue task processing - Workflow notifications - Email jobs - Retry processing for failed integrations Hangfire, .NET BackgroundService or another appropriate .NET approach can be used. Background jobs should have proper error handling and logging. 12. Notification system Users should receive notifications when relevant events occur. Examples: - Task assigned - Task approaching due date - Work order submitted for approval - Work order approved or rejected - Project status changed The first version may use in-app notifications with an architecture that allows email notifications to be added cleanly. 13. Third-party API integration The MVP should include at least one external REST API integration. The integration should demonstrate proper handling of: - Authentication - API requests - Response mapping - Error responses - Timeouts - Retry logic - Logging If the external service supports webhooks, webhook handling may also be included. We will agree on the exact external service before development begins. 14. API architecture The backend should expose clean REST endpoints. We expect: - Appropriate HTTP methods - Request/response DTOs - Validation - Consistent API responses - Pagination - Filtering - Error handling - Authorization - Swagger/OpenAPI documentation Business logic should not be placed directly inside controllers. 15. Database architecture The SQL Server database should be designed with future expansion in mind. We expect: - Proper table relationships - Foreign keys - Useful indexes - EF Core migrations - Tenant-aware data structure - Efficient queries - Appropriate delete behavior - Consistent naming The developer should review likely query patterns before finalizing indexing. 16. Error handling and logging The application should have centralized exception handling. We also need structured logs for: - Application errors - API failures - Background job failures - Authentication issues - External integrations The architecture should support Azure Application Insights or another centralized logging platform later. 17. Performance The developer should pay attention to: - EF Core query performance - Avoiding unnecessary database calls - Pagination - AsNoTracking where appropriate - Efficient loading of relationships - Indexing - Caching appropriate data Redis may be used for selected frequently accessed data where it provides a clear benefit. 18. Testing The project should include automated testing for important business logic. We expect a reasonable combination of: - Unit tests - Service-layer tests - Integration tests Priority should be given to: - Authentication - Authorization - Tenant isolation - Workflow transitions - Important APIs We are not expecting 100% test coverage, but the main business rules should be protected. 19. Docker and deployment readiness The finished project should be structured for deployment to Microsoft Azure. Expected work includes: - Docker configuration - Environment-based configuration - Production connection string handling - Secrets management approach - Database migration process - Basic CI/CD configuration A complete enterprise infrastructure deployment is outside Phase 1, but the application should be ready for it. Development approach We expect clean separation between: - API layer - Application/business logic - Domain logic where appropriate - Infrastructure/data access - Frontend We are open to Clean Architecture, layered architecture or another sensible structure. We do not want architecture added simply for the sake of complexity. The structure should make the application maintainable as additional modules are introduced. Who we are looking for We are looking for someone with strong practical experience in the Microsoft .NET ecosystem. You should be comfortable with: - C# - ASP.NET Core - .NET 8 - Entity Framework Core - SQL Server - REST APIs - Authentication and authorization - React - TypeScript - Git Experience with the following is a plus: - Multi-tenant SaaS applications - Hangfire - Redis - Azure - Docker - CI/CD - Background processing - Workflow systems - Audit logging - Enterprise business applications We care more about your ability to structure and deliver a maintainable system than the number of technologies listed on your profile. What to include in your proposal Please keep your proposal relevant to this project. Share one or two examples of ASP.NET Core applications where you personally worked on the backend architecture. For each example, briefly explain: - What the application did - Which .NET technologies you used - What part you personally developed - Any architecture or performance decisions you were responsible for Please do not send a long list of unrelated projects. Screening questions Please answer the following questions in your application: 1. How would you implement tenant isolation in an ASP.NET Core + EF Core application? 2. How would you structure role-based and permission-based authorization when different organizations may eventually require different permission configurations? 3. How would you design the workflow engine so additional workflow states and transition rules can be introduced later without hard-coding every possible workflow? 4. What approach would you use for background jobs that need retry handling and failure logging? 5. How would you prevent Entity Framework Core queries from becoming inefficient as the database grows? 6. How would you test that users from Organization A can never access data belonging to Organization B? 7. Please describe one .NET application you have personally built that is technically similar to this project. Important This contract is for Phase 1 of the platform. We are not expecting every possible enterprise feature during this phase. Our priority is getting the architecture and core modules right so the system can grow without requiring a major rewrite. We prefer a developer who communicates clearly, raises technical concerns early, commits code regularly and can explain the reasoning behind architectural decisions. If Phase 1 goes well, there may be additional development work for later modules.