Capability
Data Engineering
Nothing downstream is better than the data underneath it.
What we build
Data Pipelines
Ingestion and transformation that runs to a schedule you can trust, with late, duplicate and malformed records handled as the normal case rather than as an incident.
- Batch & streaming
- Airflow · dbt
- Change data capture
- Idempotent loads
Data Harmonization
One agreed definition of a customer, a part or a site across systems that were never designed to agree, including the reconciliation nobody wants to own.
- Entity resolution
- Canonical models
- Reference data
- Deduplication at scale
Data Platforms & Warehousing
The warehouse or lakehouse underneath it, sized to the query patterns you actually have rather than to a vendor’s reference architecture.
- Lakehouse
- PostgreSQL · Snowflake
- Partitioning
- EU data residency
Analytics & Business Intelligence
Reporting the person making the decision can read without asking an analyst to run it, with every figure reconciled back to source.
- Semantic layers
- Self-serve dashboards
- Metric definitions
- Reconciliation
Data Governance & Quality
Tests, lineage and named ownership, so a wrong number is traceable to where it went wrong instead of becoming an argument between two teams.
- Data contracts
- Lineage
- Quality tests
- GDPR · retention
We build the layer everything else stands on: the pipelines that move an organisation’s data, the models that give it one agreed shape, and the platform it gets queried from. It is the least visible work we do and the work that decides whether anything above it holds.
The problem it addresses
Most organisations do not have a data problem in the abstract. They have four systems that each hold a version of the same customer, a warehouse whose numbers stopped matching the source ledger some time last year, and a reporting layer nobody trusts enough to act on without checking it by hand. The data exists. Agreeing what it says is the work.
This surfaces hardest at the moment somebody wants to build on top of it. An estimation model, a forecast or a retrieval system will expose every inconsistency underneath it within days, and it will do so as a wrong answer in front of a user rather than as a failing test. On our engagements the first eight to twelve weeks of an AI programme is usually data work, and treating that as a surprise is how programmes lose their second year.
How this is delivered
Team shape
2 to 6 data engineers, with a platform engineer in the team
Common dynamic
8 to 12 weeks for foundations, then ongoing
Engagement model
Managed Delivery or Embedded Partnership
Delivery hub
Zagreb · Belgrade
Where a competitor would stay quiet
The trade-offs
Data work is unglamorous and it is the part of a programme a sponsor most wants to skip. We will not skip it, and we will tell you at the first call when the foundations phase is eight to twelve weeks rather than two. We also cannot fix data that was never captured. Where the history you need does not exist, no pipeline creates it, and the honest answer is to start recording it now and revisit the model in a year.
Questions procurement actually asks
With an assessment rather than a platform purchase. Discovery establishes what you hold, how complete it is and whether it can carry what you have in mind. That takes weeks, and it regularly changes what gets built.