API request
- Purpose
- Return a defined result or validation error to an interface or another system.
- Controls
- Authentication, authority and repeated-request behaviour.
.NET development for complex business software.
We use .NET to build business applications, APIs and services that connect people, records and operations. Its breadth makes it a useful foundation for a new platform, a specialist processing service or the next stage of an existing application. We bring the interface, business logic and operating requirements together around the work the software needs to support.
Applications we build with .NET
Business platforms, APIs and processing services around orders, contracts, permissions and approvals. We can build a new application, extend a stable service or replace one component.
Why we work with .NET
Choose a strength to see how it supports the application.
Performance
Asynchronous I/O, runtime optimisation and profiling help identify slow requests and resource use. We measure the bottleneck before changing capacity.
- RequestApplication workload
- ProfilingMeasured latency and resource use
- Targeted changeAddress the observed bottleneck
Development efficiency
Established tooling and libraries cover authentication, configuration, diagnostics and data access, leaving more attention for business rules. Dependencies still need deliberate selection and maintenance.
- Framework toolingAuthentication, configuration and diagnostics
- Application codeBusiness rules and data access
- MaintenanceDeliberate dependencies and upgrades
Versatility
Web applications, APIs, integrations and workers can share language and development practices while retaining separate responsibilities.
- Interface / APIRequest and validation
- C# application servicesShared language, separate responsibilities
- Integrations / workersHandoffs and deferred work
Deployment choice
Modern .NET runs across Windows, Linux and macOS. AWS, Azure, containers or other suitable hosting follow identity, workload and operating skills.
- Operating requirementsIdentity, workload and team skills
- Hosting choiceAWS, Azure, containers or other suitable hosting
- Runtime environmentWindows, Linux or macOS
Maintainability
C# types, compiler checks and tests help teams assess changes. Clear boundaries and readable code support evolving workflows.
- C# typesDefined application contracts
- Compiler and testsAssess changes before release
- Clear modulesReadable boundaries for evolving workflows
Ecosystem and support
Maintained frameworks, documentation and open-source tooling provide established options. Dependency quality and upgrades remain part of ownership.
- Frameworks and librariesMaintained implementation options
- Documentation and toolingSupport development and diagnosis
- Owned dependenciesQuality, updates and ongoing support
C# and .NET supply building blocks. Architecture, hosting and operating ownership still follow the application.
Business rules and the transaction boundary
Services enforce the rules whether a request comes from a screen, integration or job. Related database changes commit together; an external finance handoff is delivered separately.
Changed prices, simultaneous edits and disputed approvals inform the model. The example retains an order change, approval history and pending message in one local transaction.
One change. Two kinds of responsibility.
Illustrative example. Sample records.
Approve an orderInterface or API request · identity and permission checked
Inside the application
Apply the order rules
Check the current revision and approval authority.
Commit together
- Order state
- Approved
- Approval history
- Actor + revision
- Pending message
- Export requested
The order change and its pending handoff are retained together.
Outside that transaction
Delivery worker
Reads pending work.
Records attempts and results.
Finance integration
Accepts the operation or returns a recoverable exception.
Local consistency Related records change atomically in this example.
Recoverable handoff External delivery happens separately, with stable operation identity and duplicate handling.
External delivery needs operation identity, duplicate handling, monitoring and retention. This is not a reason to queue every action.
Respond now, or complete work separately
The caller’s task determines what must happen within a request.
Background work
- Purpose
- Imports, notifications, documents and scheduled reconciliation.
- Controls
- Job identity, progress, bounded retries and cancellation where appropriate.
Isolate invalid records. A failed notification should not undo a completed business action.
Keep the application understandable
Clear modules
One deployable application can have documented boundaries and testable rules. Separate services are useful when workload, ownership or release needs justify their additional contracts, delayed events and failure modes.
Database choice follows transactions, queries, retention and existing operations. A slow query, calculation and integration require different remedies; service count and extra servers do not establish architectural quality.
Extend what remains useful
Review runtime and dependency constraints, critical workflows, tests and release practices first. Modern cross-platform .NET and .NET Framework may have different environment constraints.
Protect fragile rules, improve diagnostics or establish a stable component interface before wider replacement. Recover undocumented behaviour from users, records and execution. Coexistence needs agreed record ownership, compatibility and a practical recovery path.
Deployment and ownership
Hosting follows the workload, not the language. Make secrets, access, configuration and environment differences explicit, with logs connecting actions to processing without unnecessary sensitive data.
Handover includes application boundaries, critical-rule tests, API contracts, release guidance and operating information. Start with one complete new workflow or one necessary change to an existing application.