Loading · .NET
Stack Innovations Start a project
Stack Innovations/ Services/ Custom Development/ .NET
03 / 08 · Custom Development
000Building .NET

.NET

Bespoke .NET services, engineered for the ten-year arc.

Start a build →
Median p95 latency28ms
Cold start · Native AOT180ms
Nullable warnings0
Critical vulns0
The argument

A .NET service is just C# enforcing the contract it was given.

Each nullable · a guarantee. Each record · an invariant. Each build · a contract held.
02 — Ecosystem

.NET,
and the right neighbours.

Runtime/01
.NET 9

Minimal APIs, native AOT compilation, cross-platform by default. Our baseline for every new service.

Cross-platformAOTSTS · 24mo
Framework/02
ASP.NET Core

Minimal APIs or full MVC — same runtime, your choice of ceremony.

Minimal APIMVC
ORM/03
Entity Framework Core

LINQ-to-SQL, migrations, change tracking — typed, end to end.

LINQMigrations
Language/04
C# 13

Records, pattern matching, nullable reference types on by default.

RecordsNullable
Architecture/05
MediatR

CQRS and mediator pattern for clean request/response separation.

CQRSPipelines
Testing/06
xUnit

The modern standard test framework for .NET.

FactsTheories
Cloud/07
Azure / AWS SDKs

First-class cloud integration, wherever the workload runs.

AzureAWS
Resilience/08
Polly

Retries, circuit breakers, timeouts — declarative, not hand-rolled.

RetryCircuit breaker
Logging/09
Serilog

Structured logging with sinks for every observability backend.

StructuredSinks
Deploy/10
Native AOT

Ahead-of-time compiled binaries — fast cold start, no JIT warm-up. The default for container-bound, cloud-native services.

AOTCold startContainers
Realtime/11
SignalR

WebSockets with automatic fallback, built into ASP.NET Core.

WebSocketsHubs
03 — What we build

Three shapes,
one runtime.

01 — Enterprise
Enterprise
APIs.

Line-of-business backends. Strong typing, audit trails, contracts that don't drift under load.

  • →Auth · OIDC + claims-based rolesIdentity
  • →Audit trail · every mutation loggedEF interceptors
  • →Versioned contracts · OpenAPISwashbuckle
  • →Resilience · retries, breakersPolly
claims: role=Admin AuditLogInterceptor /api/v1/orders
02 — Line-of-business
Internal
LOB apps.

Back-office, admin tooling. Tables that scale to a million rows; workflows that mirror how the org actually runs.

  • →Data grids · server-side pagingEF Core
  • →Approval workflows · statefulState machine
  • →Role-scoped views · per departmentRBAC
  • →Exports · CSV, Excel, PDFBackground job
po# status owner approved
03 — Cloud-native
Cloud-native
services.

Containerized, Azure/AWS, AOT-compiled microservices. Cold starts measured in milliseconds, not seconds.

  • →Native AOT · single static binary~180ms cold start
  • →Container images · distrolessDocker
  • →Health checks · readiness/livenessK8s probes
  • →Autoscale · request-drivenHPA
cold warm pool steady
/ Phase 01 · Discover

Listen first.

Stakeholder interviews, support tickets, existing schema review. We map the service boundaries by mapping the work.

Discovery docTech auditRisk map
SCOPE USERS DATA TEAM RISK OUTCOME
Endpoints/ MapGroup("/api/orders") .MapGet("/{id}", GetOrder) .MapPost("/", CreateOrder) .MapPut("/{id}", UpdateOrder) .RequireAuthorization() .WithOpenApi()
record OrderDto(Guid Id, string Status) record CreateOrderRequest(Guid SkuId, int Qty) FluentValidation: RuleFor(x => x.Qty).GreaterThan(0)
// OrdersEndpoints.cs app.MapPost("/api/orders", async (CreateOrderRequest req, AppDbContext db) => { var order = Order.Create(req); db.Orders.Add(order); await db.SaveChangesAsync(); return Results.Created(...) }); → EF Core migration applied → documented via OpenAPI → tested · xUnit + integration
w1 w6 w12 -36% p95 latency
01
01
05
05 — Architecture

A request,
end to end.

// live · GET /api/orders?status=open
Request Static
Client Web · Mobile · Blazor HTTPS · JSON Gateway Edge · Rate limit ~9ms TTFB API ASP.NET Core · Minimal API Auth · MediatR DB EF Core · Postgres Read replicas Observability Serilog · OpenTelemetry Logs · Traces · Metrics
Client → Gateway~9ms
Gateway → API~11ms
API → DB~6ms
Round-trip · p9528ms
06 — Numbers

Standards,
not anecdotes.

What every .NET build leaves with — the floor, not the ceiling.

Median p95 latency 0 ms · across last 12 builds
#StandardFloorMethod
01 p95 latencyAPI · production 0ms APM
02 Cold startNative AOT 0ms CI bench
03 Nullable warningsbuild with warnings-as-errors 0 Roslyn
04 Test coveragexUnit · line 0% coverlet
05 Build timeCI · dotnet publish 0s CI
06 Critical vulnsNuGet audit / Snyk 0 CI gate
08 — Engagement

Three ways
to start.

01 / Sprint2 weeks
Diagnostic
sprint.
flatfixed scope
  • →Tech audit · current .NET stack
  • →Architecture proposal
  • →Risk & cost map
  • →Live walkthrough · written report
Book a sprint →
02 / MVP— Most chosen
MVP ship.
retainer4–8 weeks
  • →One service surface, end to end
  • →Auth · Persistence · Telemetry wired
  • →API contract seed · OpenAPI spec
  • →CI/CD · monitoring · runbook
  • →Two rounds of post-launch iteration
Start an MVP →
03 / Build12+ weeks
Ground-up
platform.
retainerquarterly
  • →Multi-service platform
  • →Internal admin + customer-facing API
  • →Embedded design partner
  • →Hand-off plan, onboarded team
Plan a build →
09 — Questions

Things people
actually ask.

.NET 9 gives you a single runtime that's genuinely fast (top-tier in TechEmpower benchmarks), cross-platform, and backed by a compiler that catches whole classes of bugs before they ship — nullable reference types, exhaustive pattern matching. For enterprise and line-of-business work specifically, the tooling around EF Core, identity, and long-term Microsoft support tends to win the case outright. We reach for Node or Go when the workload is closer to a thin I/O-bound proxy than a business-rule-heavy service.
Minimal APIs by default for new services — less ceremony, faster cold start, and they compose cleanly with Native AOT. We reach for MVC controllers when a project needs model binding conventions, view rendering, or filters/conventions a larger existing codebase already standardized on. Both run on the same ASP.NET Core pipeline, so mixing them in one app is a non-issue.
Postgres is our default for new builds — open source, no per-core licensing, and EF Core's Npgsql provider is mature and fully featured. SQL Server is the right call when you're already deep in the Microsoft stack — SSRS, SSIS, Always On availability groups, or compliance requirements that specifically call for it. EF Core abstracts most of the difference at the code level either way.
Both, depending on the team and the surface. Blazor (Server or WebAssembly) makes sense when the same team owns frontend and backend and wants one language end to end — it's a strong fit for internal tools and admin panels. For customer-facing products, or where the org already has React/Vue expertise, we ship a typed REST or SignalR API and let the frontend live in its own stack — see our React-specific page for that side of the build.
Yes — this is a large share of our .NET work. We start with the .NET Upgrade Assistant and a dependency audit to flag anything tied to Windows-only APIs (System.Web, WCF server-side, full IIS modules) that needs a replacement path. Migrations typically run incrementally, side-by-side behind a reverse proxy, rather than as a big-bang cutover — so the legacy app keeps serving traffic while the new one earns trust.
xUnit for unit and integration tests, with WebApplicationFactory for in-memory API testing against a real EF Core/Postgres test container. Coverlet for coverage reporting, Roslyn analyzers and nullable warnings-as-errors gate every build. CI runs the full suite — unit, integration, and a static analysis pass — on every PR; nothing merges on a red build.
10 — Start

Let's build
something worth shipping.

Two-week diagnostic, four-week MVP, twelve-week ground-up. Bring the brief — we'll send a plan, not a pitch deck.

Start a project →
Tweaks
Accent
Motion
Lenis
Sound