How We Work With a Data Stack That's Already There

Quick answer

Stepping into a data stack someone already built means pipelines already running, some of it undocumented, and a team used to working around whatever's broken. Our process is the same every time: talk to stakeholders about what's actually going wrong, go through the code and any documentation to find the patterns and the landmines, diagram what we find and validate it with stakeholders where we can, write a risk register, then plan.

This isn't a blank-slate project. There's usually a warehouse someone set up two years ago, a few dbt models nobody's touched since the person who wrote them left, and a Slack channel where people quietly agree not to trust one of the dashboards. Here's how we actually work with that.

First, we ask what's actually wrong

Before opening a single file, we talk to whoever's closest to the pain: what broke recently, what feature someone's waiting on, what's been flagged for a refactor and never gotten to. A pipeline that fails every couple of weeks and gets manually restarted. A report that's supposed to exist and doesn't. A model everyone agrees is a mess but nobody's touched, because it's load-bearing and nobody wants to be the one who breaks it. (Sound familiar?)

Stakeholders know what hurts. The code knows why, and it rarely matches their story exactly, which is part of why both conversations matter.

Then we get into the code

We go straight into the code: how things are named, whether there's a consistent structure or every model was built differently depending on who touched it last, where the tests are (if there are any), where logic is duplicated in three places instead of defined once.

If documentation exists, we use it, but treat it as a starting point, not a source of truth. Documentation drifts from reality faster than most teams realize. Where the code and the docs disagree, the code wins, and that disagreement usually tells us something about how the team works and where things tend to slip.

Then we draw what we found

With the code read, we build diagrams: how data actually flows from source to warehouse to report, where the dependencies are, what feeds what and in what order. It's us turning what we just read into something we can actually reason about, not documentation for its own sake.

It's easy to think you understood a pipeline after reading it once. Drawing it out is what catches the parts you only sort of followed. Once the diagram holds together, we walk it past stakeholders where there are any who'd know and ask if it matches how they think it works. That step is what surfaces the dependency nobody mentioned, because to them it was never a dependency, it was just how things had always worked.

Then we write the risk register

This is the step that's easy to skip and the one we don't. Before proposing any changes, we write down the actual risks: what could break, how badly, and how likely that is. A pipeline that's fragile but load-bearing. A table three other systems depend on that nobody documented as a dependency. A single script one person understands that everything downstream quietly relies on.

It's not a formality. It's what keeps us from walking in and "improving" something that turns out to be holding everything else together, and it gives stakeholders something concrete to react to instead of a vague sense that parts of the stack feel risky. A ranked list is something you can plan around. A feeling isn't.

Then, finally, the plan

Only after all of that do we put together next steps, grounded in what stakeholders told us, what the code and documentation revealed, what the diagrams confirmed, and what the risk register flagged as most urgent. Sometimes that means fixing the fragile pipeline first because it's actively costing people time. Sometimes it means leaving something alone because it works fine and isn't worth the risk of touching yet, even if it's ugly.

We're not the person who inherits someone else's system and rewrites it because it doesn't match how we'd have built it from scratch. We're working with what's actually there, understanding it fully first, and changing what actually needs to change.

Getting this built

This process, discovery, a code and documentation pass, diagramming validated with stakeholders, and a risk register, is usually one to two weeks of focused work before the first real plan comes together. It's the same approach behind how we build low-cost, well-tested systems more generally. A fractional data engineer can run this end to end as a defined engagement, not an open-ended one, and it typically costs a fraction of a full-time hire.

Start with the roadmap below to see what this would look like for your specific stack.