Hey, I’m Tobiáš Building reliable software, data pipelines and useful automation.

What I built

Market prices, macroeconomic statistics and housing data live in many places with different formats, schedules and licences. Comparing them means reconciling units, dates and currencies by hand, and it is easy to lose track of where a number came from or whether it is still current.

• Provider adapters for public sources including ČNB, ECB, US Treasury, Bundesbank, FRED, Eurostat, ČSÚ, SEC EDGAR, the Prague Stock Exchange and CoinGecko, plus keyed sources such as Twelve Data and ČNB ARAD.
• An ingestion pipeline that validates each batch before storing it and logs every run.
• Analytics for comparing up to eight instruments: rebased performance, risk statistics, rolling correlation and same-day currency conversion.
• Czech real-estate views: regional price statistics, ARAD housing-loan data, Realitní pes listing search and an investment calculator.
• Google OAuth accounts with per-user watchlists, saved comparisons and research notes.

Engineering decisions

Provenance on every number

Each series carries its source, observation date, retrieval time and a staleness flag computed from its update cadence. The interface shows them next to the figure.

Validation before persistence

Duplicates, future dates, non-finite values, non-positive prices and high-below-low bars are rejected and counted by reason before anything reaches the database.

Quota-aware on-demand requests

Property listings come from an API with a small monthly quota, so they are fetched only on request, cached, deduplicated with a per-key lock and retried with bounded backoff.

Tests that never call the network

Provider parsers are tested against recorded responses. CI runs the backend suite on both SQLite and PostgreSQL, then type-checks, lints, tests and builds the frontend.

In the repository 150 backend tests, 7 Alembic migrations and a GitHub Actions workflow covering ruff, pytest on SQLite and PostgreSQL, TypeScript, ESLint, Vitest and a production build.

What I built

Lunches were served from a printed list: each student had to find their name, tick it off and tell the cook their meal. It was slow at peak time, names got mixed up, and a prepaid lunch was simply wasted when its owner was absent.

• The Vue 3 frontend: a student dashboard, gifting a lunch to another student, and a public pool for donating and claiming lunches.
• Admin screens for the canteen: a live card scanner, assigning ISIC cards to students, user management and daily statistics.
• The card-reader bridge: a Python client reads the card UID from an ACR122U reader and a small Node.js server broadcasts it to the app over Socket.IO.
• Google sign-in through Firebase, exchanged for the app’s own JWT, with router guards that keep admin screens behind the admin role.

Engineering decisions

REST for actions, Socket.IO for live state

Sign-in, gifting and card assignment go through REST endpoints. Scans, lunch counts and the public pool update over WebSockets, so every screen in the canteen stays current.

The reader bridge only forwards

The card-reader server just broadcasts the UID it reads. Every check happens on the backend, so the hardware side holds no rules that could drift out of sync.

Feedback built for a queue

The scanner shows exactly one of four states, each with its own colour and icon: waiting, served, warning (unknown card or no lunch) or error. After a successful scan it resets on its own, ready for the next card.

In the repository Submitted as my maturita thesis at 1. IT Gymnázium in 2026 and tested with a real ACR122U reader.

What I built

Student money is small and irregular... trust me, I would know. A monthly total does not tell you whether you can afford something today once rent and subscriptions still have to come out.

• Transactions with categories across separate card and cash wallets.
• Category budgets, savings goals and recurring bills.
• A daily spending limit based on what is left after unpaid bills.
• Reports, plus CSV and JSON export of all transactions.
• Web push reminders for recurring bills, and the EUR rate from ČNB.
• Google sign-in and email accounts with Argon2 password hashing and JWT.

Engineering decisions

Balances that stay consistent

Editing or deleting a transaction adjusts the matching card or cash balance by the net difference, instead of recalculating from scratch.

Data scoped to each account

Transactions, budgets, wallets, bills and profiles belong to the signed-in user. Registration can be limited to an allow-list of email addresses.

Careful file uploads

Profile photos are decoded with Pillow with decompression-bomb checks before they are stored.

In the repository Includes a Render blueprint that deploys the API with persistent storage and the static client.