About Marcin
I run into a problem, figure out what's actually going on, then build or adapt something to deal with it. That's been the pattern for as long as I've done technical work — long before AI made it faster.
I spent seven years working professionally in IT at ZUS in Poland.
Background
My role there was Junior Computer Scientist — Help Desk, Local Admin and Application Admin work. One piece of it stuck with me: I automated a maintenance process that used to take roughly four hours down to about ten minutes.
I later moved to the UK. Alongside driving HGVs, which I still do, I also spent a few years running a small UK transport company — real contracts, fleet compliance, and the kind of day-to-day operational constraints that don't show up in a spreadsheet. I wound it down voluntarily in 2025.
None of that was software. But it's the same underlying habit: understand what's actually happening, build or run the system properly, and be honest when something isn't working.
The common thread
Most of what I build now follows the same shape: a real problem shows up, I understand it properly, then build or adapt a system around it — and use that system for real, not as a portfolio piece.
Deal Analyser exists because I wanted honest numbers before any money moved on a property deal. TRON exists because I wanted AI-assisted security monitoring for my own homelab, without ever giving an AI the authority to act on its own. HGV HUB exists because working-time and compliance tracking is a real problem I actually have, not a hypothetical one.
How I build
AI is leverage, not an identity. I still make the calls that matter — what the actual problem is, the requirements, the architecture and trade-offs, what gets tested before I trust it, when something's ready to deploy. AI is what lets me turn those decisions into working software faster than I could alone.
The other habit is writing down what a thing doesn't do. The project pages here carry the limits next to the capability — what isn't built yet, where a rule I set isn't kept, what a tool refuses to answer. Some of the Notes are entirely about defects in my own work, including one where the code was correct, the tests passed, and nothing in the running system ever called it.
Most of what I run is private — a homeserver, household software, security tooling on my own infrastructure. That doesn't stop the reasoning being public. Architecture, trade-offs and mistakes can be written up without publishing data, addresses or infrastructure, and where it made sense a couple of the projects are open source outright.
Property
Property is a long-term direction for me, not something I'm already running. I'm building toward it properly — real deal analysis with Deal Analyser, published reasoning on UK property and regulation, and enough patience not to rush a deal just to have a story to tell.
Where I can genuinely help today, it's by working through the numbers and the realistic routes, and pointing people to the right specialist — not by pretending I'm already running a portfolio.