These three pieces show three different sides of the work: a multi-tenant business system running in production, measurement data I produced myself, and an architecture where data never leaves the company. Each page states the stack, the decisions taken and why.
A multi-tenant CRM for the curtain and home-textile trade. Angular + Ionic/Capacitor front end, Node.js/Express + Sequelize back end, MySQL 8, Redis/BullMQ, MinIO. In production on a single VPS with Docker Compose and continuous delivery via GitHub Actions.
Role: technical lead · 2025–2026 · Shipped
I measured open-weight model performance on real coding tasks on an Apple M5 Max with 48 GB unified memory. Harness ±11 points, task design ±18, sampling parameters ±2–3.
My own measurement · 2026 · Ongoing
An engine that turns spreadsheet-driven processes into an installable desktop application and sends nothing to the cloud. Tauri 2 + Angular + embedded SQLite.
My own product · 2026 · In development
All three are about drawing a boundary. In the multi-tenant CRM the boundary is between customers; in the local LLM measurement it is between what a model can and cannot do; in the desktop engine it is whether data leaves the device at all. The real job of software architecture is not adding features — it is making those boundaries impossible to cross by accident.
| Work | Role | Core technology | Status |
|---|---|---|---|
| Multi-tenant CRM | Technical lead | Angular · Ionic · Node.js · MySQL 8 | In production, shipped |
| Local LLM benchmark | Ran the measurement | Apple Silicon · MLX · open-weight models | Ongoing |
| Local-first desktop engine | Founding developer | Tauri 2 · Rust · Angular · SQLite | In development |
Retail and dealer-network management, industrial electronics, games, IT consulting and recruitment, and surveying. What interests me is less the domain knowledge than the problem all of them share: a business unable to describe its own rules precisely enough for software. That is where most projects stall — not on technology.
Client names and commercial figures are not published without written permission. Everything on these pages is either my own work or technical detail I am allowed to share. If you want references I will make the introduction during a call — putting something on the internet and sharing it in a conversation are not the same thing.
A classic case study describes the client and the outcome; these pages describe the decision and the reasoning. The reason is simple: whoever decides who gets a software contract wants confidence in the judgement behind the work, not a sentence saying the client was pleased. Where I have no measurement I do not invent a metric — I write the verifiable technical fact instead.
Last updated: