df-flow.dev
PL EN
Let's talk

data → reports → decisions

Data that works for your decisions

I build systems that connect data from your existing tools, clean it, and turn it into ready reports and dashboards — no manual copy-pasting, no spreadsheets stitched together after hours.

Let's talk
years working with data
12+
reports a year in a system I built
~1,500
records in a single analysis
up to 120M
faster analyses after moving computation to the database with dbt
60–70%

layer: services

What I can build for you

BI reporting and dashboards

Self-updating KPIs and reports. One screen instead of ten spreadsheets.

Data pipeline automation

No more manual copying and busywork. Data from your systems connects, gets cleaned, and reports itself automatically — every day, without you lifting a finger.

Spatial analytics

Location-based analysis: POIs, building types, catchment areas, and site potential. An answer to the question ordinary analytics can't see: where?

Forecasting and anomaly detection

Predictive models built on your data — from diesel fuel consumption forecasts for 2,000 HP generator sets to catching unusual costs and fraud before they grow.

layer: contrast

Same company, two Mondays

without automation

The report gets stitched together by hand from spreadsheets, late on a Friday.

Data scattered across systems — every department has different numbers.

New location decisions made by gut feeling.

Job pricing based on manual guesswork.

with automation

The report generates itself and is ready Monday morning.

One source of truth: data connected, cleaned, consistent.

Every location's potential scored against the same measurable criteria.

Cost forecasts from a model, with scenarios to compare.

layer: work

Systems already running

service: data pipeline automation

Self-service reporting platform — 1,500 reports a year with no manual work

I built an on-demand analytics system. Analyses launch from three places — a web app, an Ubuntu terminal, or a scheduler — and are heavily customized through parameters. Prefect splits jobs into fast and slow queues, a Python script fetches and validates the data, and DataFrame computation handles up to 80M records. Results land in PostgreSQL and OneDrive, Slack notifies on start and completion, and the web app shows queue status and usage stats: who, how often, how long, with which parameters.

Self-service reporting platform architecture A web app, Ubuntu terminal, and scheduler send jobs to Prefect with fast and slow analysis queues. A Python script fetches and validates the data, DataFrame computation covers up to 80 million records, and results land in PostgreSQL and OneDrive. Alongside: Slack notifications and usage-stats monitoring. Web app Ubuntu terminal Scheduler Prefect queue: fast queue: slow Python script fetch & validate Computation DataFrame up to 80M records PostgreSQL OneDrive Slack notifications Monitoring web usage stats

~1,500 reports/year · 5 min–12h per analysis · up to 80M records · Docker + Kubernetes

service: BI reporting and dashboards

Analytics in the browser — results 60–70% faster by moving computation to the database

Analyses launch straight from the web app, Prefect queues the computation, and dbt handles extraction, transformations, and the computation itself — all inside the database, not in Python. Tables, ready-made charts for client reports, and a full analysis history come back to the browser. I process data where it lives instead of pulling it out first — that alone cut analysis time by 60–70%.

Browser-based analytics architecture built on dbt The web app triggers analyses, Prefect queues the computation, and dbt performs extraction, transformations, and computation inside the database — making analyses 60 to 70 percent faster. Results return to the web app as tables, charts, and analysis history. Web app analysis trigger Prefect computation queue dbt extraction · transformations in-database computation 60–70% faster analyses Web app — results tables · charts · history

up to 120M records · analyses 60–70% faster

Repeatable location scoring for every new site

Challenge
The client needed a repeatable way to score retail locations — a process, not a one-off analysis.
Solution
I combined three data layers: public (GUS population density, building footprints), competitive (competitor brand locations gathered automatically from public websites), and behavioral (the client's own POI foot-traffic data). The process scores location potential, movement between points, and the character of the surrounding retail environment.
Outcome
A repeatable process instead of one-off analyses — every new location is scored against the same measurable criteria.

Python · SQL · PostGIS

Bid pricing from a forecast, not from manual estimates

Challenge
The company priced drilling jobs from rough fuel-consumption estimates for its 2,000 HP generator sets; every new job meant a manual, time-consuming cost estimate.
Solution
I cleaned several years of the client's operational data and enriched it with public data pulled automatically from a national geological survey. I built a multiple regression model with variants for winter/summer season and crew size.
Outcome
Automated forecasts that adapt to each new job — faster, more accurate cost estimates, and side-by-side scenarios before deciding.

Python · pandas · scikit-learn

Real, not theoretical visibility for every billboard

Challenge
The client knew each billboard's parameters — coordinates, azimuth, range — but not where it was actually visible from; theoretical range ignores obstacles.
Solution
From those parameters I generated visibility footprints and clipped them against real obstacles — buildings with their actual height, plus parks and trees — using public building data.
Outcome
A map of each billboard's real, not theoretical, visibility — the basis for pricing ad space and scouting new locations.

PostGIS · Python · public spatial data

layer: process

How we'd work together

  1. A conversation about the problem

    No strings attached. We figure out what hurts most today and what data actually exists.

  2. Data review and a quote

    I look at your data and propose a scope of work with a concrete price.

  3. Rollout in stages

    Working pieces every week or two, not a big reveal after six months.

  4. Maintenance and growth

    The system stays with you, or runs as a subscription on my servers.

layer: about

Who's behind this

I'm Sebastian Sobiech, a BI data engineer and GIS specialist — I've been working with data for over 12 years. I live in Zielona Góra (Poland) and work remotely with companies across the country.

education

  • 2022–2024 Postgraduate studies, Data Engineering — Warsaw School of Economics (SGH)
  • 2012–2016 Engineering degree, Power Engineering — State Higher Vocational School
  • 2009 Internship — Astronomical Observatory, Adam Mickiewicz University in Poznań
  • 2004–2009 Computational astrophysics — University of Zielona Góra

PostgreSQL/PostGIS · Python · dbt · Prefect · Oracle · GCP · QGIS/ArcGIS · Docker/Kubernetes

51.94°N 15.50°E — Zielona Góra

Let's talk about your data

Describe in a few sentences how your reporting works today — I'll tell you what can be automated and where to start. Write in too if you'd rather just set up a call.