Small, explicit changes
In a live system a precisely named rule, an isolated mapping or one focused
test usually beats a big rewrite. Less to go wrong at 2 a.m.
About me
Senior backend and integration engineer — Kotlin, Java, Spring, PostgreSQL and the production systems that run on them.
I'm at my best where correctness, compatibility and release safety actually matter. My job isn't only writing backend code; it's owning the place where implementation, domain behaviour, integration contracts and production releases overlap. I like to help, I keep learning, and I try not to pretend to be more than I am.
How I think about software
Modern when it pays off
I like new versions and tools — but only when they make the system more
reliable, more observable or easier to change. Not for the CV.
It's not done at deploy
The real system starts after deployment: old data, retries, external
contracts, logs, metrics and whoever has to support it.
Career path
A compressed timeline of how my responsibilities evolved across projects and stack changes.
2017-2018: ZIS
Enterprise Java, ZK/ZUL screens, controllers, services,
DAO layers, imports and production fixes. This was the phase
where I learned to deliver complete application features.
2019-2020: MNCP
Full-stack work across Kotlin/Spring, Angular and database scripts.
I worked on security, exports, archives, measuring batches and operational
fixes across the whole flow.
2020-present: TSM
Senior backend and integration work on Kotlin/Java/Spring services,
PostgreSQL, Kafka-style integrations, B2B flows, incident analysis
and production rollout of new platform versions.
2024-present: Nordic / Django (ad-hoc)
Ongoing on-demand collaboration in a Django stack, plus personal experiments.
Low volume now, but the engagement stays open. A reminder that good engineering
habits should transfer across stacks, not depend on one framework.
Working style
Architecture and responsibility
Good architecture is not about complexity or diagrams. It is about
responsibility, ownership and understanding where changes should
and should not happen.
Collaboration
The best solutions usually come from collaboration between developers,
analysts, product owners and operations. Technical decisions should
serve the product and the people who keep it running.
What I deliberately avoid
Over-engineering
I avoid adding architecture that does not reduce real complexity,
risk or maintenance cost.
Trend-driven decisions
I like modern tools, but only when they clearly improve delivery,
reliability or developer understanding.
One-person architecture
A system is not well designed if only one person can safely change it.
Ego-driven choices
Technical decisions should serve the product and runtime behavior,
not personal taste.
Off the clock
I build things end to end partly because I genuinely enjoy this stuff. Here's the human behind the commits.
Reading & audiobooks
Around 125 books and counting — LitRPG (Vasily Mahanenko), a lot of Czech
sci-fi/fantasy (Kotleta, Sněgoňová, Starý, Kadlečková, Stehlíková), plus
Andy Weir, Liu Cixin, Sapkowski and Pratchett. I do most of it as audiobooks.
Anime
Grew up on the shounen Big 3 (Naruto, One Piece, Bleach). One Piece is the
one still running — and I'm still watching.
Gaming
My main way to switch off. PlayStation 5, currently playing Saros.
Metal & coffee & bikes
Iron Maiden, Arch Enemy, Jinjer, HammerFall and friends in the headphones.
Coffee ground fresh in a hand mill and brewed in a moka pot. A bike waiting
for a rebuild. Cats and dogs both welcome.
From Horní Radechová near Náchod, in the Krkonoše foothills.
now_playingSaros (PS5)
now_readingMycelium — Vilma Kadlečková
now_watchingOne Piece
Let's work together
If this approach matches what you need, feel free to reach out.