Analytics and prediction platform on TimescaleDB

This is our own product. We built it and maintain it ourselves. It is not a client commission or a demo: it runs in production on our VPS with real users. In data work, that is stronger evidence than a declaration.

What it is

A platform that collects data continuously, stores it as time series, and turns it into metrics, forecasts, and reports.

• Collectors running as continuous services fetch, normalise, and save data; monitoring exposes interruptions.
• A time-series database—TimescaleDB on PostgreSQL—is the single source of truth for measurement history.
• An analytics and prediction layer runs statistics and models on the same data without manual spreadsheet exports.
• An interface with dashboards, roadmap, and audit tab makes project state visible rather than narrated.
• Recurring reporting, including investor reports, and deployment announcements sent to Discord.
• A Discord user community provides the shortest feedback loop: reports reach us immediately, not at a quarterly review.

What problem it solves

• Data is scattered and there is no overall picture. A report is assembled manually, so it is infrequent and always late.
• A measurement without history cannot answer “is this better than last month?” Time series retain every state, not only the current one.
• A laptop pilot cannot answer “what happens overnight?” A server-side collector can, and reports if it stops collecting.

How we built it

Collectors are Python services running continuously on a VPS and watched by monitoring. A key design decision is that a collector failure must be visible: a data gap is worse than no data because it can look like a valid result.

Data goes to TimescaleDB: PostgreSQL with time partitioning and time-series aggregations. Python and FastAPI provide the logic and API; Next.js and React provide the interface. Database migrations live in the repository and are checked before server delivery. A daily audit checks migrations, logs, and whether collectors actually collect data, recording discrepancies as a repair plan.

Deployment consists of a VPS, system services, monitoring, and backups. We deliberately avoid a “magic cloud deploy”: the environment can be described, recreated, and handed over with the code.

What it demonstrates

It demonstrates that we can deliver a data system to production and stay with it, with collectors, monitoring, migrations, and reporting rather than only a dashboard screenshot. It is direct evidence for data and analytics; the collectors are a production example of process automation.

We do not show anyone else’s data: it is our own platform, so we can speak openly about architecture and mechanics. See how we work and what we build with.