It starts with the data, not the tools
I like good tooling. I want to say that first.
When it's the right fit, tooling lets small teams do a lot with a little. That's real and I've seen it work.
But here's the thing that doesn't change no matter what tools you buy: bad data in, bad data out. A six-figure system that moves bad data quickly hasn't solved anything. It's just faster garbage.
Are you buying tools or solving problems?
Before adding anything to a stack, I try to ask one honest question: how do I solve this problem in the most accurate, efficient, scalable way given where we actually are right now?
Not where we want to be someday. Right now.
I've worked with teams running every tool you can name, and the person running the business still couldn't get a reliable answer on their most important number. That happens when the stack becomes the goal instead of the means.
Nobody asks how you built it
Stakeholders don't ask what language you used to calculate churn. They don't ask whether the report was built in SQL or Python. They ask:
- Is this number right?
- Is it recent enough to act on?
- Can I get it again next week?
That's the bar. A well-maintained spreadsheet can clear it. A complex pipeline can fail it. The tool is not the point.
Every tool you add is a commitment
Licenses. Maintenance. Documentation. Training the next person. Debugging on a Sunday night before a Monday morning meeting.
Those decisions usually made sense when they were made. Someone knew a certain tool. Someone read a post about best practices written for a team ten times the size. Context matters more than best practices. The right tool is the simplest one that actually solves the problem you have.
The spreadsheet test
Before I add anything new, I ask: could a spreadsheet handle this?
Not forever. Not at scale. Just right now.
If the answer is yes, you probably don't need the new tool yet. You need the answer. Get the answer first. Upgrade when the pain is real and specific, not when you're worried about looking behind.
I've replaced broken pipelines with a Google Sheet more than once. Not because that's where you stay. Because the team needed numbers they could trust that week.
When simple really isn't enough
There is a point where the simple setup breaks. The cron job gets unreliable. The volume outgrows the tooling. That's real and it's part of the job to recognize it.
But upgrade because something is actually breaking, not because of general anxiety about your stack not being modern enough. If your setup gets accurate data to the right people on time at a cost that makes sense, it's working. That's not a compromise. That's the job done.
What I actually look at
When I look at a data setup, I'm not comparing it to some ideal. I'm asking:
- Can the team keep this running without it becoming someone's whole job?
- Could a new person understand it in their first week?
- Does the cost make sense for the value it provides?
- When something breaks, how fast can you fix it?
- Are the people who need data actually getting it?
If yes, I don't care what's under the hood.
Simple is the harder skill
Saying "we don't need that yet" takes real discipline. Shipping something plain that works every single time takes confidence.
The best data people I've worked with aren't the ones who know the most tools. They're the ones who know what to leave out.
The stack isn't the product. It's how you get to the product. The goal is a business making better decisions because the numbers are right, timely, and not too expensive to keep running.