01
Case studies
Case studies.
Client names are withheld by agreement. The technical detail is accurate, and we will walk through any of it in a conversation under an NDA.
02
Industrial
Asset management platform
fig. 01
Asset management and maintenance across an industrial operation.
.NET 8
Blazor Server
SQL Server
SQLite
Multi-tenant cloud
On-premises
253-entity domain model
The situation
A heavy-industry client needed maintenance and asset management across eleven functional areas of their operation. Reliability, work orders, the full spread.
The constraint
Two of them, pulling in opposite directions. Some sites had no reliable connectivity. And their largest customer required a genuine on-premises deployment rather than a private cloud tenancy with a reassuring name on it.
What we built
Most vendors solve this by maintaining two products, which means two release cycles, two sets of bugs, and a customer somewhere always running the older one. We built one architecture instead: a 253-entity domain model on .NET 8 and Blazor Server, deploying either as a multi-tenant cloud platform or as a fully on-premises installation, with tenant routing across both SQLite and per-tenant SQL Server underneath.
Where it got difficult
Keeping one codebase honest across two deployment targets is a discipline you keep paying, not a decision you take once. Every feature has to work without the cloud services a developer reaches for by default, and every release has to be installable by somebody who is not us, on hardware we have never seen.
Where it stands
One codebase. One release cycle. A platform in production, with the on-premises and cloud deployments on the same version as each other.
03
Agentic
Agent inside an operational system
fig. 02
Agentic process automation, running in production.
Anthropic SDK
Agentic automation
Defined boundaries
Escalation to a person
Full action record
The situation
A step in an operational process was being done by a person, repeatedly, against data that already existed in the system. It was the kind of work that is too varied for a rule engine and too routine to be a good use of anyone’s shift.
The constraint
Getting it wrong quietly was worse than not doing it at all. Anything acting on its own inside an operational system needs a record of what it did and why, and a person in the path at the points where a wrong answer costs something.
What we built
An agent built on the Anthropic SDK, working inside the existing application and against the real data model, not alongside it. It has defined boundaries on what it may do unsupervised, escalation to a person where the stakes justify it, and a full record of its actions. The infrastructure, the tests, and the hosting around it are the same as for any other part of that system.
Where it got difficult
Most of the engineering was not the model. It was deciding what the agent was allowed to do, what it had to hand back, and how anyone would tell afterwards whether it had behaved. We took that pattern from building compliance systems, where every action needs an evidence trail.
Where it stands
In production, as part of software people use to do their jobs, not as a demonstration. It is one deployment. A decade of practice is a different claim and we are not making it.
04
Mining
Offline-first operations capture
fig. 03
Mining operations without a signal.
Offline-first
Local capture and reconciliation
Hosted integration API
Continuous deployment
The situation
A metals business needed its operations captured at the point they happen, by the people doing the work, rather than reconstructed afterwards from paper and memory.
The constraint
The places where the work happens do not have reliable connectivity, and the people doing it are not going to stop working because a spinner is turning. An application that requires a connection gets abandoned within a week and replaced by a notebook.
What we built
An offline-first application. It works fully without a connection, stores what happens locally, and reconciles when signal returns. Alongside it, a hosted integration API so the operational data reaches the rest of the business instead of staying in the app. It deploys continuously, straight to production, which is defensible because the tests and gates in front of it are real.
Where it got difficult
Treating offline as a normal state rather than an error condition reaches into every part of the design. How records are identified when two devices generate them independently. What happens when two people edited the same thing in different valleys and both come back online on the same afternoon. Those decisions have to be made at the start, because retrofitting them means rewriting the data layer.
Where it stands
In daily production use, in an environment that defeats most software, feeding a business that no longer waits for the end of a shift to find out what happened during it.
Claer & Volker
453 Winifred Yell St, Garsfontein
Pretoria, South Africa
info@claervolker.com
© 2026 Claer & Volker
·
·