Almost every conference talk about data infrastructure is given by someone who works at a company with a thousand engineers and a data platform team to match. The tools and patterns they describe are often genuinely good ideas. They are also usually the wrong ones for a 30-person company trying to answer questions like "which of our three sales channels is actually profitable."
I have set up or rebuilt the data stack for eleven client companies over the past few years, ranging from a seed-stage startup with two founders to a 180-person manufacturing business. The pattern that works is almost the opposite of what conference talks recommend: fewer moving parts, more boring choices, and a stack you are allowed to outgrow.
The three questions that actually matter
Before naming a single tool, we ask clients three questions. The answers tend to matter more than any feature comparison.
- Who will maintain this in a year? If the answer is "whoever is around," pick tools with the smallest possible operational surface. A managed service you pay for beats a self-hosted open-source tool that nobody currently on staff has run in production.
- How many people will actually query the data? If it is fewer than five, an elaborate semantic layer or BI platform with row-level permissions is solving a problem you do not have yet.
- What decision is this meant to inform? If nobody can name a specific decision, it is worth pausing the tooling conversation and figuring that out first.
A stack that has worked for us more than once
For a company under 50 people with a handful of source systems (a product database, a payments processor, maybe a support tool), this combination has held up well across several client engagements:
| Layer | What it does | Why boring wins here |
|---|---|---|
| Managed warehouse | Stores and queries your data | No servers to patch, scales without a migration project |
| Managed ELT connectors | Moves data from source systems into the warehouse | Someone else maintains the API integrations as they change |
| SQL transformation tool | Turns raw tables into clean, documented models | Version-controlled, testable, and readable by the next hire |
| One BI tool, used consistently | Dashboards and ad hoc queries | A second BI tool "for the exec team" is a recurring source of conflicting numbers |
Notice what is missing: a dedicated orchestration platform, a feature store, a real-time streaming layer. Every one of these solves a real problem at sufficient scale. At the scale most of our clients operate, they add operational burden that outweighs the benefit.
The best compliment I have gotten on a data stack build was from a client's new data hire, six months after we finished the project: "I understood the whole thing by my second day, and I have been able to just add to it since."
Where teams get this wrong
The most common mistake is not a bad tool choice. It is copying the stack of a company at a different stage, usually because someone read a well-written blog post from a company with a hundred times the headcount and the budget to match. The second most common mistake is building for a scale you may never reach, at the cost of shipping something useful this quarter.
We also see the opposite failure less often but just as painfully: a company stays on a spreadsheet-and-manual-export process two years past the point where it was genuinely fine, because nobody wants to be the one to propose spending money on tooling. If your finance team is manually reconciling numbers from three systems every month, that manual process has a cost too, even though it never shows up as a line item.
Revisit the decision on a schedule, not a crisis
Every stack we build includes a note in the documentation: revisit this in 18 months, or sooner if the company doubles in headcount or adds a genuinely new data source, like a second product line with its own database. Putting a date on the revisit, rather than waiting for something to break, keeps the conversation calm and grounded in actual growth rather than a fire.