What we build with, and why
What gets used depends on your environment and on who looks after the application after handover.
Frontend
Tools
Angular with RxJS, HTML5, CSS3, Tailwind CSS, high-performance grids for data-heavy screens
Clerical work means the same screen a hundred times a day, and lists with five-figure result counts have to filter in the browser as fast as they did in the old fat client.
Backend
Tools
Node.js with TypeScript or ASP.NET, plus Python and Go for throughput and special tasks
If you already run a .NET environment, we build in ASP.NET. Otherwise, we use Node.js with TypeScript. Python or Go are added only where throughput requirements or a specialist task call for them.
Databases and legacy data
Tools
Microsoft SQL Server, PostgreSQL, MongoDB where needed, plus DBF, DBC and Access
We connect the legacy formats read-only, so data can be reported on or migrated while the legacy system keeps running unchanged.
Mobile in the field
Tools
Ionic with Capacitor for Android and iOS, capture by EAN and QR scan
Out there what counts is that a delivery or a return is recorded at the moment of the scan; the predecessors of such apps still ran on portable MS-DOS mini PCs at our clients.
Data and reporting
Tools
HydraData as the data pump, Power BI, Microsoft Fabric with PySpark, InfluxDB as a time-series source
HydraData extracts data from systems that make access difficult and writes it to a SQL database. Power BI connects to that database, rather than to the data pump’s internal intermediate layer.
How we use AI
AI in our own work and AI in your application are two decisions we take separately.
In our own work since 2022
Before that we ran machine learning with TensorFlow for stochastic analysis. Today AI is part of the toolkit when reviewing code, running security checks, understanding unfamiliar processes and for part of the implementation.
No vibe coding
Every line a tool contributes passes through a developer before delivery. We are liable for the result exactly as if we had written it by hand. We tested that on a tool of our own that assesses security findings and checks the impact of changes. The review applies there too, where no client asks for it.
Which model gets to see what
Before a model goes near your code or your data, we ask you. For non-sensitive material we use Claude or GPT on business plans where the provider may not use your content for training; for sensitive data an open-source model runs locally at our end, and in client environments we have integrated smaller models on site, which keeps the data in house and cuts ongoing API costs.
Rarely the answer inside your product
Where a transaction must be auditable, such as an accounting entry or an anti-money-laundering check, an answer that changes on the next run is unsuitable. If a fixed rule does the same job, we say so. An exception is extracting reports that arrive only as PDFs. We use Azure AI Document Intelligence in that data flow and retain the raw output so every figure can be traced back to its source.
We continue to develop HydraData, our script-driven data pump for .NET, as an open-source project. It is available under the MIT licence, with source code at github.com/crossvault/hydradata.
Understand your situation. Agree the next steps together.
Tell us what works today and what you would like to change. The first conversation is free and without obligation; afterwards, you receive an initial assessment or possible next steps. You incur costs only when you accept a proposal. For a more detailed business and technical assessment, we agree a separate engagement in advance, with a clear scope and limits on time and cost.
Discuss your project