.NET Development in the US

About .NET Development

We take on .NET builds as a senior engineering service: ASP.NET Core web apps and Web APIs, enterprise backends, and moving legacy .NET Framework code onto a modern, cross-platform stack. It is a newer service line for us, so we will say so plainly. You get senior engineers, a written scope, and a flat quote, and we lean on the API design, testing, CI, and migration work that carries straight over from the rest of what we build.

What the engagement includes

• You already run on Microsoft: SQL Server, Azure, Active Directory, or a team that standardizes on C#. .NET fits that estate with far less friction than bolting on a different runtime.
• You need a fast, strongly typed backend for high-throughput APIs. ASP.NET Core on Kestrel is genuinely quick, and static typing catches a whole class of bugs before they reach production.
• You are modernizing an old .NET Framework or WebForms app and want to stay in the same language and hiring pool instead of rewriting in something unfamiliar to your team.
• Your team hires C# developers and will own the code after us. Handing a Node or Laravel app to a .NET team, or the reverse, is a real long-term cost worth avoiding.
• If none of that is true and you are starting fresh with no Microsoft ties, we will often steer you to Node or Laravel instead, the stacks we run deepest in. Saying that costs us the .NET brief and saves you money, which is the trade we would rather make.

Azure Government endpoints, Login.gov sign-in and the CJIS Security Policy in US .NET work

US public sector and defense buyers on the Microsoft stack often run in Microsoft's government cloud, and a .NET codebase written against commercial defaults does not simply deploy there. Azure Government is a separate instance with its own endpoints: Entra ID signs users in at login.microsoftonline.us rather than login.microsoftonline.com, Key Vault lives under vault.usgovcloudapi.net, Blob storage under blob.core.usgovcloudapi.net, Azure SQL under database.usgovcloudapi.net and App Service under azurewebsites.us. Microsoft Graph splits again by Microsoft 365 environment: a GCC tenant keeps using graph.microsoft.com, GCC High uses graph.microsoft.us and DoD uses dod-graph.microsoft.us, and a token issued for one cloud is not accepted by another. In .NET that makes the cloud a setting rather than a constant scattered through the code. Azure.Identity credentials take AzureAuthorityHosts.AzureGovernment, each service client is built from a base URI read from configuration, the Graph client gets its national base URL, and Application Insights is pointed at its government ingestion endpoint through the connection string. Microsoft's own guidance warns that most published samples assume global Azure, which is where hard-coded hosts come from. Feature gaps change designs too. Azure AD B2C is not available in Azure Government, so a citizen-facing ASP.NET Core app cannot borrow the customer identity pattern it would use commercially. App Service managed certificates are unavailable, so certificate renewal becomes your job. And Azure Lighthouse cannot delegate a subscription across a national cloud and the public cloud, so an outside team works through accounts issued in your government tenant rather than from its own. Microsoft limits its own personnel's access to systems processing customer data to screened US persons; how your tenant treats a vendor's engineers is your decision. We keep a parity checklist per release and run integration tests against a government subscription before promising a feature. Which cloud your contract requires is for your contracting officer.

For a public-facing ASP.NET Core application run by a federal agency or a state, local or territorial government, sign-in is increasingly Login.gov, the federal shared service that holds a FedRAMP Moderate authorization, rather than an identity system the project builds. Integration is standard OpenID Connect with firm rules. Login.gov does not accept client secrets at all: a web application authenticates to the token endpoint with private_key_jwt, a JWT signed with a key of at least 2048 bits, PKCE is the method it prefers for native mobile apps, and the implicit flow is not supported. Every authorization request carries prompt=select_account and nonce and state values of at least 22 characters, and acr_values sets the service level: auth-only for a plain account, verified for identity verification, and verified-facial-match-required or verified-facial-match-preferred where a program needs a facial match, with the older IAL and LOA values kept only for legacy compatibility. In ASP.NET Core most of that lands in the OpenID Connect handler's events. The redirect event adds prompt and acr_values, chosen per route, so a benefits application asks for verification while a status check asks only for sign-in, and a user who arrives with a lower level is sent back up rather than let through. The token request carries a client assertion signed with a key held in Key Vault or a certificate store, never a secret sitting in appsettings, and key rotation is a scheduled task with overlap so sign-in never breaks on the changeover. The sandbox at idp.int.identitysandbox.gov and production at secure.login.gov are separate registrations, so the environment is chosen by configuration, and a staging build cannot reach production by accident. Verified attributes such as a Social Security number are requested only where the program needs them, and the user record stores what the program uses rather than everything Login.gov can return. Whether your program may use Login.gov, and at which level, is for the agency's identity and privacy officials.

If the .NET system touches criminal justice information, such as a police records system, a jail or court case system, or a dispatch integration that queries state and national files, the governing document is the FBI's CJIS Security Policy, now version 6.1 of 25 June 2026. Its personnel screening control requires state of residency and national fingerprint-based record checks before anyone is given access, with access approved by the CJIS Systems Officer or another designated official, and a private contractor reaches the data only under the CJIS Security Addendum attached to its agreement with the agency. Screening built around residency and fingerprints in a US state is not something an engineer in India can complete, so the honest design keeps unencrypted criminal justice information out of our reach altogether: development and test run on synthetic records, production access stays with the agency's vetted staff or a US contractor that has signed the Addendum, and our work reaches production through the agency's own pipeline. The logging control lands in the .NET code. AU-2 lists events to log, successful and unsuccessful alike: log-on attempts, attempts to use access, create, write, delete or change permissions on accounts, files, directories or other resources, password changes, actions by privileged accounts, and attempts to access, modify or destroy the audit log itself. In ASP.NET Core that means authorization outcomes, failures included, are emitted from the authorization handlers as structured events rather than left to framework debug output, Identity's sign-in and password events are captured with the source address, SQL Server Audit covers what database administrators do, and the audit store is one the application can write to but nobody on the development side can read back or delete. AU-2 is a Priority 2 control in the zero-cycle that ends on 30 September 2027, after which it becomes sanctionable, while AU-11's one-year retention of audit records is an existing requirement already audited. Whether your system processes criminal justice information is for your agency's CJIS Systems Officer.

How we work with US clients

A US engagement gets agreed twice. Once with the person who wants the thing built, and then again with legal, security, procurement and finance, who arrive separately and rarely in the same week. That second round is where a supplier outside the country loses the calendar: a master services agreement to redline, a security questionnaire, a certificate of insurance, and a vendor portal that assumes everyone it onboards can sign a W-9. Send all of it while the scope is still being written rather than in the week you wanted to start, and where the honest answer to a row is that we do not hold something, we write that in rather than leaving it blank.

You are also buying from a company you cannot drop in on, so the evidence has to do the work an office would otherwise do. What we send is live production URLs rather than a deck, a written scope with one fixed number against it, and the names of the people who will do the work rather than a bench that changes after signature. What we will also tell you is the shape of what you are hiring: a small team in Noida that has been building since 2021, not a firm that can put four more people on your project next Monday. If that is what your timeline needs, we say so before the contract rather than after it.

Questions US clients ask

.NET Development: common questions

Other markets we work in