What Does a Dot Net Developer Do?

A dot net developer designs, builds, tests, deploys, and maintains software on Microsoft’s .NET platform. The job centers on C#, ASP.NET Core, APIs, databases, authentication, automated testing, cloud infrastructure, and production support. Senior .NET developers also make architecture decisions that determine how software handles transactions, concurrent requests, external integrations, security controls, and failures.

For a CTO or engineering leader, the distinction between writing C# and engineering a production .NET system matters. A developer who knows syntax produces features. An experienced .NET engineer understands how those features behave under load, during deployment, after an API timeout, and when the same financial request reaches the system twice.

A .NET developer turns product requirements into applications and services that run on the .NET platform. That work covers application architecture, backend development, API design, data access, testing, deployment, monitoring, maintenance, and technical documentation.

The exact balance follows the product. A SaaS platform places more emphasis on tenant isolation, subscription logic, APIs, and integrations. A FinTech product adds transaction integrity, audit records, authorization, reconciliation, and strict data handling. A HealthTech application places greater weight on access control, traceability, sensitive-data handling, and reliable integrations with external systems.

1. Build backend services and business logic

Backend development forms the core of many .NET roles. Developers use C# and ASP.NET Core to implement APIs, workflows, validation, calculations, background processes, and integration logic.

Consider an insurance platform that calculates premiums from customer details, policy rules, risk data, and underwriting criteria. The difficult part is not returning a number from an endpoint. The developer has to keep pricing rules consistent, validate incomplete or conflicting inputs, preserve calculation history, and make rule changes without breaking existing policies.

That work requires clear domain models and well-defined boundaries between business rules and infrastructure code. Experienced .NET developers keep core logic separate from controllers, databases, and external services so that important rules remain testable and easier to change as the product evolves.

2. Design APIs and external integrations

.NET developers build REST APIs, event-driven integrations, webhooks, internal service interfaces, and connections to third-party platforms. ASP.NET Core provides the application layer, while the engineering work includes contracts, authentication, versioning, error handling, rate limits, timeouts, and observability.

API design starts with the contract rather than the controller. A stable contract defines request and response formats, error semantics, authentication requirements, versioning rules, and ownership of each operation. This prevents internal implementation details from becoming permanent public dependencies.

Code & Pepper's work on NoMo provides a concrete example. NoMo is a personal finance management application created by DirectID. Code & Pepper's published backend case material describes a complex application refactor in which the backend was rewritten in .NET, hexagonal architecture was introduced to support cloud infrastructure, and the application was integrated with Open Banking APIs. The published project data also lists 16 connected banks and three months of data for cash-flow analysis, giving the example a defined technical result rather than reducing it to a list of frameworks.

Code & Pepper provides this type of work through its .NET development services and backend development services.

3. Model data and protect transaction integrity

.NET applications frequently use relational databases such as SQL Server or PostgreSQL, with Entity Framework Core handling object-relational mapping. Database work includes schema design, queries, migrations, indexes, transactions, concurrency control, and performance analysis.

The important part is preserving business rules when several operations happen at the same time. Imagine a wallet with a $100 balance receiving two simultaneous requests to withdraw $80. Both requests read the same starting balance unless the application and database enforce the correct concurrency strategy.

The solution belongs in the system design. Optimistic concurrency works well when conflicting writes are uncommon. Database transactions protect operations that require atomicity. Explicit locking fits narrower cases where serialization is part of the business rule. The developer selects the mechanism from the consistency requirement rather than adding locks after a production incident.

4. Implement authentication and authorization

Authentication establishes identity. Authorization determines what that identity is allowed to do. .NET developers implement both at the API, service, and data-access layers.

ASP.NET Core supports identity systems, claims-based authorization, role-based controls, policies, OAuth 2.0, and OpenID Connect integrations. Production systems also require token validation, secret management, least-privilege access, audit events, and clear boundaries between privileged and ordinary operations.

In regulated products, authorization belongs to the business model. A support employee viewing a customer account, an administrator changing permissions, and an automated service initiating a transaction represent different actors with different privileges. Treating all three as generic authenticated users creates a security design problem.

5. Write automated tests around business risk

Professional .NET development includes unit, integration, API, contract, and end-to-end tests. The test mix follows the consequences of failure.

A pricing formatter needs fast unit tests. A payment workflow needs tests around transaction state, duplicate requests, integration failures, authorization, and reconciliation. An Open Banking integration needs contract tests that detect changes in external behavior before those changes affect users.

The same principle applies to CI/CD. Tests belong inside the delivery pipeline rather than in a separate phase after development. Code & Pepper's 2026 guide to DevOps testing explains continuous testing across the software delivery pipeline, including the role of testing in regulated products.

6. Deploy and operate .NET applications

A developer's responsibility continues after compilation succeeds. Production software requires repeatable deployments, configuration management, logs, metrics, traces, health checks, rollback procedures, and incident diagnostics.

.NET applications run on Windows and Linux and fit containerized and cloud environments. Teams deploy them through Azure, AWS, Kubernetes, managed container platforms, virtual machines, and platform services according to operational requirements.

The architecture needs to expose enough information to diagnose a failed request. Structured logs identify what happened. Metrics show the scale of the problem. Distributed traces connect operations across service boundaries. Correlation IDs tie user-visible failures to backend activity.

The tooling around these practices is covered in Code & Pepper's DevOps tools guide for 2026, which organizes delivery tooling around version control, CI/CD, infrastructure, testing, monitoring, and security.

A modern .NET stack combines the runtime and language with frameworks, databases, cloud services, testing tools, and delivery infrastructure.

The presence of these technologies on a CV does not prove seniority. Seniority appears in the decisions around them: transaction boundaries, API contracts, failure handling, data consistency, deployment safety, observability, and the amount of operational complexity introduced by the architecture.

A C# developer is defined primarily by programming language expertise. A .NET developer works across the broader platform, including application frameworks, runtime behavior, data access, deployment, integrations, testing, and production operations.

The titles overlap because C# is the dominant language in modern .NET development. The practical distinction appears when the job expands beyond implementing classes and methods.

Take a transfer endpoint as an example. Writing the controller and calling a payment service demonstrates C# development. Designing idempotency, transaction state, authorization, retry rules, reconciliation, database constraints, monitoring, and rollback behavior demonstrates .NET system engineering.

This distinction also explains why hiring teams get poor results from technology checklists. Asking for "five years of C#, ASP.NET Core, SQL, Azure, and Docker" describes exposure. Architecture questions reveal whether a candidate understands what happens when those components interact.

Retry logic is one of the clearest examples of the difference between feature implementation and production engineering.

Assume a customer submits a payment request. Your .NET service sends the request to a payment provider, but the HTTP connection times out before the provider's response reaches your application. The service now lacks information about whether the payment succeeded.

Automatically sending the same operation again creates a duplicate-payment risk.

An idempotency key gives repeated requests the same operation identity. The service stores that identity with the processing state and result. When the same request arrives again, the application returns the existing result or continues the existing workflow instead of creating another transaction.

A simplified flow looks like this:

1. The client generates or receives an idempotency key.
2. The API checks whether that key already exists.
3. A completed operation returns its stored result.
4. An operation in progress returns the defined in-progress response.
5. A new key creates a new operation record.
6. The business transaction executes once against that identity.
7. The final state remains available for later retries and reconciliation.

Database constraints reinforce the design by preventing two concurrent requests from creating two records for the same idempotency key.

This pattern matters far beyond payments. Account creation, subscription changes, order placement, document generation, and webhook processing all contain operations where duplicated execution creates inconsistent state.

.NET fits products that need long-term maintainability, high-throughput backend services, strong typing, mature tooling, and integration with Microsoft or cloud infrastructure. It is especially relevant for transaction-heavy applications, enterprise SaaS, FinTech platforms, internal business systems, and APIs with complex domain logic.

ASP.NET Core gives engineering teams a mature web framework with dependency injection, configuration, authentication, logging, and cross-platform runtime support. C# provides static typing, asynchronous programming, modern language features, and a large ecosystem.

The commercial decision still starts with the product architecture. A startup with a small CRUD application has different engineering constraints from a lending platform processing financial data across multiple providers. The stack earns its place through operational requirements, team expertise, integration needs, and expected system lifetime.

For financial products, Code & Pepper's Open Banking development services illustrate the connection between API engineering, security, data aggregation, and financial infrastructure.

Modern .NET and the older .NET Framework are different platforms from a lifecycle and modernization perspective.

Microsoft currently lists .NET 10, .NET 9, and .NET 8 as supported releases. .NET 10 is an LTS release supported until November 2028. .NET 9 is an STS release supported until November 2026, while .NET 8 is an LTS release whose support also ends in November 2026. These dates come directly from Microsoft's .NET releases and support documentation.

.NET Framework remains relevant in existing Windows applications, but new cross-platform development centers on modern .NET. A modernization project therefore starts with an inventory of runtime versions, dependencies, Windows-specific components, authentication mechanisms, database access, integrations, deployment infrastructure, and automated test coverage.

Migration planning follows those dependencies. A system with isolated business logic and strong automated tests supports incremental migration. A tightly coupled application built around unsupported libraries requires more restructuring before runtime migration starts.

FinTech places engineering pressure on transaction integrity, data access, authentication, external integrations, auditability, and operational visibility. .NET developers working in this environment spend substantial time on system boundaries rather than isolated application features.

Open Banking demonstrates the point. The application receives financial data through external providers, maps that data into an internal model, applies business logic, stores selected information, exposes results to users, and records enough context for troubleshooting and audit work.

Code & Pepper's published DirectID work gives this example measurable scope. Its Open Banking service material lists 13,000+ bank connections, 12 months of transactional data, and one unified API integration in connection with the DirectID project. The same page states that the work included custom API development and Salt Edge integration, with compatibility, security, and QA as explicit engineering concerns.

Those figures belong to that specific published project description. They are not market averages, generic Open Banking benchmarks, or promises for another implementation.

A useful case study identifies the starting problem, the engineering decision, and the resulting product capability. Oathello provides that evidence more clearly than a technology inventory.

Oathello set out to create a self-service platform for document completion, signing, and verification. Code & Pepper's published case study states that the founders first needed an MVP to prove the concept and support investor conversations. The engineering team used an API-first architecture because external platform integration formed a core part of the product.

The resulting product supported online document completion, digital signing, document tracking and recall, and multi-level signing and witnessing workflows for integrations. The case study reports that the product reduced the document certification process from weeks to minutes.

The client's own assessment provides first-hand evidence about the engagement. Duncan Campbell, Head of Product at Oathello, said Code & Pepper "proactively redesigned the product to enhance the final version."

Code & Pepper's .NET service material also identifies .NET Core and React as technologies selected for the Oathello web application, connecting the project outcome to the stack discussed in this article.

Salary comparisons require matching the same job title, geography, source, and reporting period. Mixing a ".NET Software Engineer" average with a ".NET Developer" range produces a misleading comparison because salary databases classify those titles separately.

For the United States, Salary.com reports an average base salary of $96,340 per year for the exact job title ".NET Developer" as of September 1, 2026. The same dataset places the 25th percentile at $87,333 and the 75th percentile at $104,157.

For the United Kingdom, Indeed reports an average base salary of £55,258 per year for ".NET Developer." Its figure is based on 16,400 reported salaries and was updated on September 7, 2026. Indeed lists a broader reported range from £37,189 to £82,106.

The ranges use each source's own methodology, so the U.S. and UK range columns describe different statistical cuts. The table labels those cuts instead of presenting them as equivalent measurements.

Salary also differs from the cost of outsourced development. Salary data covers employee base compensation. A software development partner's rate includes a different commercial model, so combining those numbers into one "developer cost" benchmark creates a false comparison.

A reliable delivery estimate comes from scope decomposition rather than a generic number of weeks. Engineering teams estimate defined capabilities, dependencies, integration work, migration requirements, test coverage, security work, deployment infrastructure, and acceptance criteria.

An API endpoint backed by an existing database represents a different scope from a financial workflow involving identity verification, multiple external providers, asynchronous processing, reconciliation, administration tools, monitoring, and audit records. Putting both under a generic "API development" estimate hides the work that drives delivery time.

A practical estimation process starts by identifying business capabilities. Each capability is then broken into application logic, data changes, integrations, test work, infrastructure, security requirements, and release dependencies. The estimate becomes defensible because every number maps to identifiable work.

For teams improving that delivery process, Code & Pepper's DevOps process flow guide describes the sequence from planning and coding through testing, deployment, operation, and monitoring.

The largest .NET project risks usually come from architecture and operational decisions rather than from the C# language itself.

Unsupported or near-end-of-support runtimes

A supported runtime receives security and servicing updates. Microsoft lists .NET 8 and .NET 9 support as ending in November 2026, so systems remaining on those versions need an upgrade plan aligned with their release calendar.

Excessive service decomposition

Splitting a small application into many independently deployed services adds network communication, distributed tracing, deployment coordination, contract management, infrastructure, and incident-response work.

Service boundaries earn their cost when they reflect genuine scaling, ownership, isolation, or deployment requirements. A modular monolith provides clear internal boundaries without introducing distributed-system overhead when one deployment unit fits the product.

Weak observability

A production API without structured logs, metrics, traces, and correlation identifiers turns incidents into guesswork. Observability design belongs in development because the application itself owns much of the context required for diagnosis.

Missing failure semantics

Every integration needs defined behavior for timeout, rejection, duplicate delivery, partial completion, invalid responses, and delayed processing. The application also needs a defined source of truth for reconciliation after an ambiguous result.

Insufficient automated testing during modernization

Legacy modernization changes infrastructure while preserving existing business behavior. Automated characterization and integration tests establish that behavior before major refactoring starts.

Code & Pepper's DevOps best practices guide for 2026 covers delivery practices around CI/CD, testing, monitoring, security, and operational feedback.

A strong hiring process tests engineering judgment through concrete production scenarios. Framework trivia provides little evidence about how a developer designs systems.

Ask the candidate to design an operation that transfers money between two accounts. Then introduce two simultaneous requests, an external API timeout, a repeated client request, a deployment during processing, and a requirement to explain the transaction history six months later.

A senior candidate identifies the relevant engineering concerns and connects them: transaction isolation, idempotency, authorization, durable state, retry boundaries, reconciliation, audit records, observability, deployment behavior, and automated tests. The explanation also identifies where each guarantee belongs, including the database, application service, API contract, message broker, and external provider.

Code & Pepper's .NET development service focuses on .NET engineering for FinTech and HealthTech products, where these system-level concerns form part of everyday product development.

These questions cover practical .NET development topics that sit outside the main sections above. They address team structure, frontend work, legacy systems, cloud deployment, and the skills needed to work effectively in a .NET environment.

Does a .NET developer work on the frontend?

A .NET developer primarily works on backend services, APIs, application logic, and data access. Full-stack .NET developers also work with frontend technologies such as React, Angular, or Blazor when the role covers both client-side and server-side development.

What is the difference between a .NET developer and a full-stack developer?

.NET describes the development platform, while full-stack describes the scope of the role. A full-stack .NET developer works across the backend and frontend, combining technologies such as C#, ASP.NET Core, SQL, and Entity Framework Core with a frontend framework such as React, Angular, or Blazor.

Do .NET developers need SQL skills?

Yes. Backend .NET applications frequently store business data in relational databases, so developers need practical knowledge of SQL, schema design, indexes, transactions, query performance, and data migrations. Entity Framework Core reduces repetitive data-access code, but it does not replace an understanding of database behavior.

Do .NET developers need cloud experience?

Cloud experience is part of many modern .NET roles because production applications frequently run on Azure or AWS. Developers working on cloud-hosted systems need to understand application configuration, identity, managed services, containers, monitoring, scaling, and deployment pipelines in addition to application code.

Can .NET developers build microservices?

Yes. ASP.NET Core supports independently deployable HTTP and gRPC services, while the wider .NET ecosystem supports messaging, background processing, containers, and distributed tracing. Teams still need a clear architectural reason for microservices because service decomposition introduces network, deployment, monitoring, and data-consistency complexity.

Can .NET be used to modernize legacy applications?

Yes. Teams use modern .NET to replace or restructure applications built on older .NET Framework versions. Modernization work typically covers runtime migration, dependency replacement, architecture changes, automated testing, deployment infrastructure, and removal of Windows-specific dependencies where cross-platform operation is required.

Do .NET developers need DevOps skills?

.NET developers need enough DevOps knowledge to understand how their applications move from source code into production. That includes CI/CD pipelines, containers, environment configuration, automated testing, logs, metrics, health checks, deployment strategies, and production diagnostics.

What does a .NET developer need to know about security?

A .NET developer needs practical knowledge of authentication, authorization, secure secret handling, input validation, dependency management, encryption in transit, access controls, and secure API design. Developers working with financial or health data also need to translate the product's security and regulatory requirements into concrete technical controls.

How do you assess a .NET developer during an interview?

Use a realistic engineering problem instead of relying on framework trivia. Ask the candidate to design an API or business workflow and explain data modeling, authentication, failure handling, testing, deployment, observability, and performance decisions. The reasoning behind those decisions provides stronger evidence of engineering depth than memorized C# syntax.