Quick answer
Most companies start analytics by plugging a BI tool straight into their operational database, and that works fine for a while. It stops working once you have more than a couple of people touching the data, because the hard part was never the data itself, it's keeping the definitions consistent as more people rely on them. The fix isn't a better dashboard, it's a modeled layer that everyone works from.
Key takeaways
- Plugging a BI tool into your operational database works fine with a small team, and stops working as the team grows.
- Disagreeing numbers are usually a definitions problem, not a data quality problem.
- Pipelines should be designed for maintenance from the start. It's cheap with five pipelines and expensive with fifty if you skip this.
- Every project should aim for two things: a source of truth, and a way for people to actually self-serve from it.
Your operational database works, until it doesn't
For product companies especially, it's completely normal to start with a BI tool sitting directly on top of the operational database. If you have one data analyst, or even a small handful, this works fine. They know the definitions, they know where things live, and they can hold all of it in their head.
The break happens when the team grows. Once you have more analysts working with the same data, it gets hard to keep everyone's definitions aligned. Not because anyone's doing bad work, but because "what does success look like in this data" is a genuinely hard question, and it gets harder every time you add another person answering it their own way. We see the same pattern from the other side in why your team keeps asking for the same numbers.
The real problem isn't data quality, it's definition quality
This is the part that surprises people. When a growing team's numbers start disagreeing, the instinct is to assume the data itself is bad. Usually it's not. The data is fine. What's missing is a shared, written-down definition of what each metric actually means, so two people looking at "revenue" or "active customers" aren't quietly calculating two different things. This is the exact gap behind why sales and finance disagree on revenue.
With a small team, this is manageable because people talk to each other. With a bigger team, it's not. The fix is building the data model first, and having the team work from that predefined base instead of everyone deriving their own version from raw tables.
Feel like your team has outgrown your current setup?
We can tell you exactly where the definitions are breaking down and what to build instead.
See how fractional works →Why we design every pipeline for maintenance first
Here's something that doesn't show up until later: five pipelines are easy to maintain no matter how they're built. It's the fiftieth pipeline that breaks you, if you didn't think about maintenance from day one. Once you have a lot of pipelines, going back to change all of them because the hierarchy wasn't thought through properly gets expensive fast.
So on every project, we design for maintenance before we design for anything else. No client wants to pay a team just to keep something running instead of building new things. If a solution takes a lot of ongoing maintenance to keep alive, that's a sign it wasn't built right the first time.
Source of truth and self-serve, the two things every project chases
Two things we work toward on every engagement. The first is a source of truth, a place where the whole business can agree that's the real number. That part takes time to get right, but it's worth it.
The second is self-serve. A source of truth that only two people in the company can actually query isn't worth much. If people still have to wait on someone else to pull the number for them, you haven't solved the actual problem, you've just moved it. Both pieces have to be there for the investment to pay off. Getting there usually means pulling every tool into one place first, the same work we cover in how to consolidate data from multiple tools.
This is what we build
We design the modeled layer and the pipelines behind it so both of those pieces, a source of truth and real self-serve access, hold up as the team keeps growing, not just on day one. See how we architect this as a fractional data architect.