Selected work

Problem, intervention, measured result

Client results usually live behind confidentiality agreements. Where we can name the client, we do. Where we cannot, we keep the method and the scope and leave the identity out.

Sub-secondcritical reporting path on live operational dataConstruction & infrastructure group · 2022–2026

An operational and financial platform, from first line to production in two months

Problem: A growing group needed an internal platform for operations and finance, fast, and one that would keep up as rules and volumes grew.
What we did: Started from a reusable core we had built on our own time. Full ownership: data model, architecture, C#, SQL, testing, deployment. Later, an optimisation programme removed repeated calculation, reused stable datasets and controlled combinatorial growth. Ana Maria validated results before each release.
Result: In production two months after the first line of code. The critical reporting path brought to sub-second response. Observability, alerts and regression detection built in; migration path to current .NET prepared.

6×2.4 s → 0.4 s, analysed and fixed in about 20 minutesVente-Privée (Veepee) · 2008–2013

Five years of platform continuity through hypergrowth

Problem: The internal SharePoint platform used across departments had to keep pace with rapid European growth, and its home page had become slow.
What we did: Primary hands-on technical ownership: development, administration, deployment, support, training. About 80 Web Part applications built within an estate of around 100; the 2013 redesign delivered in about three weeks.
Result: Third-party code on the portal home page taken from 2.4 s to 0.4 s, validated across environments and in production within two hours.

90 mininstead of a weekend, for about EUR 6 of computeEverest Software · 2016–2019

6,000 advertisement videos, rendered in parallel on Azure Batch

Problem: A digital-signage platform for automotive showrooms across Western Europe had to generate thousands of personalised videos, and a single machine took days.
What we did: Rebuilt the pipeline on Azure: rows read from SQL Server, videos generated on about 200 parallel Batch workers, output to Azure Storage, results written back through a C# API. Replaced each showroom's Windows PC with an Android device reading its playback plan from a REST API.
Result: About 90 minutes and roughly EUR 6 per full run. Hardware per showroom unit down from about EUR 600 to about EUR 50.

100×30 s → 0.30 s per page, 100,000+ rowsDP2I · 2003, where the method began

ID-first paging, still faster than today’s default

Problem: A listing used by about 20 French real-estate agency networks loaded ~60 fields over more than 100,000 rows to display one page.
What we did: Separated row identification from full row loading: order identifiers only, isolate the page, then fetch complete rows for those IDs alone. Generalised into an adaptive one-, two- or three-stage strategy.
Result: From about 30 seconds to 0.30 seconds per page. Re-measured in 2026 on 10 million rows: 9× faster than OFFSET/FETCH on the last page.

3public assessment questionnaires, still liveOrdinul Arhitecților din România · 2024–2025

Housing assessment tools for the Romanian Order of Architects

Problem: The Order wanted households to evaluate their housing, clarify priorities and test a specific property against them, online.
What we did: Built three linked questionnaires on ASP.NET MVC 5 and SQL Server: category scoring, generated recommendations, server-side PDF reports from the same views as the on-screen result.
Result: Live at locuire.oar.archi. Results exported to Excel by the Order’s own administrators, without going through the supplier.

9 yearscontinuous responsibility, three SharePoint generationsEurope Airpost · 2005–2014

One airline platform, owned for nine years

Problem: An airline needed an intranet and business applications that would survive upgrades, reorganisations and daily production use.
What we did: Installed and migrated SharePoint 2003 → 2007 → 2010; built business Web Parts and about ten internal ASP.NET applications on one shared engine. Ana Maria developed SharePoint and ASP.NET functionality and supported users.
Result: Nine continuous years of production support on the same platform, with each generation migrated rather than rebuilt.

~8,000business values verified in a few hoursConstruction & infrastructure platform · 2022–2026

Checking the data before it reaches the client

Problem: An urgent delivery depended on thousands of calculated business values being right, with no time for a second round.
What we did: Ana Maria checked roughly eight thousand values against their expected results and documented each deviation precisely enough to be corrected directly.
Result: Data confirmed before delivery; errors caught while there was still time to fix them.

Reproducible evidence

Where every figure can be published and checked

Because client numbers are confidential, we rebuilt the same problem on our own synthetic data: a 2011 hotel-reservation application over 10 million rows, implemented four times, from classic ASP.NET to an ASP.NET Core 8 API with React, Vue and Angular clients. Every implementation had to return the same rows as well as be fast.

Public benchmark repository

216measured requests

4server-side implementations

3data volumes, up to 10M rows

0client datasets used

Built on our own time

Models that became the basis of paid work

Since 2004, we build reusable application cores between engagements. The 2004 engine carried ten years of French enterprise assignments. The 2018–2021 multi-site core put a client platform into production in two months. Five sites built on it are still live:

Have a platform that is getting slower, older or harder to change?

Send us a short description. The first conversation is free and without commitment.

Get in touch