Service
Data infrastructure that holds up in production
Your data lives in a dozen systems, nobody agrees on which number is right, and every new project starts by rebuilding the same extraction. Any model you put on top of that inherits the mess.
The problem is rarely the tool
Most data infrastructure projects we inherit didn’t fail because someone picked the wrong database. They failed because nobody defined what the data was for. Pipelines were built source by source, each report computed its own version of revenue, and the logic ended up in spreadsheets that one person understands.
So we start with the questions the business needs to answer and work backwards to the sources. That tells us what to ingest, what to model and, just as important, what to leave out.
What we build
We design the architecture, build the pipelines and model the data so the same definitions feed dashboards, reports and ML models. We use managed services when they save you operations work, and open-source tools when they save you money or lock-in.
- At Aeropuertos Argentina we migrated the ETL processes from Power Query to PySpark across 35 airports. The main pipeline went from 45 to 15 minutes, and reporting error dropped by 5%.
- At Grupo Patagonia reporting went from days of manual Excel to dashboards that update in minutes, on a datalake built on the client’s own infrastructure.
- At Agrology we unified two ERPs into a 100% serverless platform on AWS (Lambda, S3, Glue and Redshift).
- At Moni the new data infrastructure cut operational costs by 50% and made pipeline development five times faster.
Right-sized, not over-engineered
A startup with a few gigabytes doesn’t need the platform a bank needs. Over-engineering costs you twice: once to build it and again every month to maintain it. We propose the simplest architecture that solves your problem today and can grow when you do.
What stays when we leave
Your team gets the code, the documentation and the knowledge of why each decision was made. If we keep working together, it’s because there’s more to do, not because nobody else can touch the pipelines.
What you get
Architecture sized to your problem
A design that fits your data volume, your team and your budget. If the data fits in memory, you don't get a Spark cluster.
Pipelines that run without babysitting
Ingestion, transformation and orchestration with tests and alerts, so failures show up in a log and not in a board meeting.
One source of truth
A lake, warehouse or lakehouse where business definitions live once, and reports and models read from the same place.
Documentation your team can use
Runbooks, data contracts and a handover, so the next change doesn't need us.
How we work
Diagnosis
The real problem isn't always the obvious one at first glance. We see the situation without the bias of being inside the organization.
Right-sized solution
We propose the simplest and most fitting solution for your specific problem. Never a bazooka to kill a mosquito.
Installed capacity
When we're done, your team has full ownership of the solution. If we keep working together, it's because you want to and we can help, not because we've got you trapped in a black box.
Related cases
Transportation
Aeropuertos Argentina
ETL migration and data governance across 35 airports: control and efficiency that reduced processing time from 45 to 15 minutes.
Agro-tech
Agrology
A data-driven product that needed new data infrastructure.
Banking
Grupo Patagonia
Automation and visibility: the best starting point.
Further reading
DBT in Action: Build the Marts Layer That Connects Your Data to the Business
Marts are the layer where your DBT models become truly useful: curated datasets, ready for analysis and business decisions.
Models, Sources, and Seeds in dbt: A Complete Tutorial for Transforming Data with Reproducible SQL
Master dbt with this hands-on guide: learn how to create models, declare sources, and manage seeds using Docker and Postgres. A step-by-step tutorial to accelerate your modern data stack and achieve reproducible, reliable data transformations.
How to Add Local Generative AI to Grafana and Turn Charts into Decisions
Integrate a local language model (LLM) into Grafana and turn your dashboards into intelligent decision-making tools. In this step-by-step guide, we show you how to visualize, analyze, and interpret metrics in real time without exposing data to external services.
Frequently asked questions
Do we need a data warehouse before doing AI?
You need reliable data in one place. Sometimes that is a warehouse, sometimes a well-ordered lake, sometimes a few tables in the database you already have. We decide that in the diagnosis, based on what you want to answer and how much data you have.
Which clouds do you work with?
Mostly AWS, also Azure, and your own servers when that's the constraint. At Grupo Patagonia we built the whole datalake on the client's on-prem infrastructure with open-source tools.
Can you work with our current stack and team?
Yes, and we prefer it. We extend what already works, replace what doesn't, and document everything so your team can run it after we leave.
How long does a data infrastructure project take?
It depends on the number of sources and how broken they are. Our recent projects ran between 5 and 6 months. A 4-week First Step gives you a diagnosis, a working prototype and a roadmap before you commit to anything bigger.