I’m a data and AI engineer based in Prague. I own the full analytics stack at UrbanStack — ingestion, warehouse, metric layer, dashboards, alerting, and the LLM systems that read them — and I consult for early-stage startups that need the same but can’t justify a full-time hire yet.
The work
At UrbanStack (formerly DIM 9000), a proptech SaaS, I am the analytics function. Everything from ingestion to the CEO dashboard to the alerts that fire when something breaks — that’s mine.
The stack is GCP-native: PostgreSQL replicating into BigQuery, a dbt project of 124 models and 376 tests across five domains, and four Next.js dashboards served from it. The alerting layer I built from scratch — Cloud Scheduler, Cloud Functions, Slack webhooks — designed to be completely quiet when things are fine.
The piece I care most about is the metric registry: 155 definitions that live in git, with coverage enforced at build time, so a metric means one thing everywhere and a dashboard card without a definition fails the build. Most of the hard bugs I have found were two honest definitions of the same word drifting apart — and once you have seen that happen, it is also the reason I don’t let a language model invent its own.
I joined as a part-time intern in July 2025, helping with dashboards and ad-hoc SQL. By October I had taken on the full analytics direction solo — not because I asked for the title, but because the work needed doing and I was the one doing it.
How I think about problems
I’m the kind of person who won’t let a problem go until it’s actually solved — not patched, solved. That stubbornness comes in handy in data work, where the real issue is almost never the first thing you find.
At the same time I try to stay honest about what’s useful. A beautiful pipeline that nobody acts on is just an expensive hobby. I want the work to matter to the business, not just to me.
The builder part
Somewhere between engineering and creativity is where I’m most comfortable. I built this website because I wanted to understand how it should work, not because I needed one. At work I’ve coded tools for myself — small automations, monitoring scripts, shortcuts that don’t exist anywhere else — because building the right tool is faster than tolerating the wrong workflow.
That instinct started with Formula 1. F1 produces enormous amounts of telemetry data — lap times, sector splits, tyre compounds, weather — and someone built FastF1, a Python library that surfaces all of it. I started playing with it and realized that data stops being abstract when it’s attached to something you actually care about. The F1 dashboard project came out of that.
The stack I reach for
- Warehouse: BigQuery with dbt — staging, intermediate, marts; tests that fail the build rather than the dashboard
- Semantic layer: a metric registry in git, coverage checked on every build
- Ingestion: managed replication from PostgreSQL, plus Python extracts for the sources it doesn’t cover
- Orchestration: Cloud Scheduler triggering GitHub Actions, after measuring that GitHub’s own scheduler skipped days without anything turning red
- Serving: Next.js dashboards over static exports of the marts — no API server, because at this size there doesn’t need to be one
- AI: Anthropic and Gemini APIs, MCP servers, RAG and agent loops — with an evaluation set, because a demo is not a measurement
- Alerting: anomaly detection on a schedule, posting to Slack only when something is actually wrong
- Tooling: Git for everything, SQL for thinking, Python for automation
Outside the work
Economics and Management student at Vysoká Škola Finanční a Správní in Prague (class of 2028), with a focus on business analytics.
Languages: Ukrainian and Russian (native), English (C1), Czech (B1 and improving).
If the race is on, I’m watching it.