.NET and ASP.NET Core Development
We build business systems on .NET: ERP and back-office applications, web applications, Web APIs, background jobs and integrations. C# and SQL Server are the core of most of what we deliver, and we take on both new builds and existing .NET systems that need continuing development.
The scope, and what has to get right.
-
BUILDNew systems on current .NET. Applications built on current .NET rather than on whatever was current when the project started, so the platform is still supported in five years. -
INHERITExisting .NET systems. Taking over a codebase someone else wrote, including older .NET Framework applications, and continuing development on it rather than insisting on a rewrite. -
SUPPORTOngoing development. Most of our .NET work is long-running: the same system, extended year after year, with the people who built a module still maintaining it.
What we build on .NET
ERP and business systems
Order, inventory, purchasing and accounting systems where the business logic is the hard part.
Read moreWeb applications
Internal tools, customer portals and multi-user applications running against a shared database.
Read moreWeb APIs and integrations
Services that other systems call, and the integrations that connect yours to trading partners, marketplaces and accounting.
Read moreSaaS products
Multi-tenant products where one deployment serves many customers, with tenant isolation designed in from the start.
Read moreBackground jobs and scheduled work are part of every one of these. They are usually where the real processing happens, and they are the part most often left out of a plan.
What we actually work in
These are the parts of the .NET platform our delivered systems run on. Each one appears in the stack of a system we have built, rather than in a list of things we could pick up.
-
.NET 8Current .NET. The target for new builds and for systems moving off .NET Framework. -
CORECross-platform .NET. The runtime underneath current ASP.NET applications and services. -
ASP.NETASP.NET MVC. The web framework behind most of the business applications we maintain. -
C#C#. The language almost all of our back-end work is written in. -
EFEntity Framework. Used where an object model earns its keep, typically for application data. -
DAPPERDapper. Used where the query matters more than the object model, typically for reporting and high-volume reads. -
WEB APIWeb API. For services consumed by front ends, mobile applications and other systems. -
SQLSQL Server. The database behind most of what we build, including the reporting work below. -
PGSQLPostgreSQL. Used where a product or client is standardised on it, including a multi-tenant SaaS platform we build. -
QUARTZQuartz.NET. For scheduled and recurring background work inside an application.
SQL Server work, not just application code
On business systems the database is usually where the difficulty lives. We do schema design, stored procedures, and the query work that decides whether a screen takes a moment or a minute.
Reporting is treated as its own problem. That means data marts built for the questions people actually ask, and read-only reporting replicas so that analysis cannot slow down the system taking orders.
Our ERP AI assistant case study is the clearest example of that data-mart work: refreshes that load into staging tables and swap in one transaction behind a row-count guard, so a failed refresh cannot leave a reporting table empty.
How the work is usually structured
Fixed-scope builds, where the deliverable is well enough understood to agree up front. These suit a defined module, an integration, or a first version.
Ongoing development and support, which is how most of our .NET work actually runs: a system in production that keeps being extended. That side is covered on IT support and maintenance.
Taking over an existing .NET system, including older applications that need to move forward rather than be replaced. Where that means moving off .NET Framework, the approach is on legacy ASP.NET modernization.
Inside the system, not bolted on.
Current platform for new work
New builds target current .NET, because a system started on an already-old version inherits a migration before it ships.
The database designed, not accumulated
Schema and queries are designed for how the data will actually be read, rather than growing one column at a time until reporting becomes impossible.
Inherited code read before it is changed
On a system someone else wrote, the first work is understanding what it does. Rewriting what you have not understood is how working behaviour gets lost.
Maintaining and extending a lone worker safety SaaS platform
- Found and fixed a structural multi-tenant flaw: Identified a structural issue in how the inherited codebase isolated data between tenant companies, and corrected the isolation model so each company's safety and account data stays properly separated on shared infrastructure.
- Automated missed-checkout detection: A background process continuously watches for missed checkouts with no manual oversight, triggering escalation in near real time rather than waiting for someone to notice.
- Added an automated phone check-out flow: Built a phone-based IVR flow through SignalWire: the system calls the worker, plays safety prompts, and confirms safety through a keypress, alongside the existing push and SMS channels.
- Subscription billing kept self-correcting: Chargify handles recurring billing with card capture fully delegated to its hosted pages, and a scheduled job syncs subscription state daily, deactivating employees at expired companies automatically.
- Added a background-check integration: Layered in PeopleConnect background-check lookups with per-user monthly usage caps, extending the platform's screening capability without disrupting the core monitoring engine.
Also relevant: A profitability and re-marketing system for a US Amazon seller , Order-to-cash ERP for a US orthotic and prosthetic manufacturing lab
Common questions.
Do you take over existing .NET codebases?
Yes, and a good share of our work starts that way. We read the system before changing it, because the undocumented behaviour in a working application is usually the part that matters most.
What is the difference between .NET Framework and .NET 8?
.NET Framework is the older Windows-only platform that is no longer gaining features. .NET 8 is the current cross-platform line. The practical issue is dependencies: a Framework application tied to Windows-only components needs those addressed before it can move.
SQL Server or PostgreSQL?
Whichever your system already runs on, or whichever your hosting and team can support. Most of our work is on SQL Server, and we build on PostgreSQL where a product is standardised on it.
How do we start?
Tell us what the system has to do, what it connects to, and whether it already exists. We will tell you what we think the work involves before anyone commits to a scope.
Have a .NET system that needs building, or one that needs someone to take it over?
Tell us what it runs on today and what it has to connect to, and we will tell you what the work actually involves.