Data plumbing is product work

A lot of product work hides in data plumbing. The user never asked for a sync runner, a raw-events table, or a better ingestion path. They asked for a dashboard they can trust, a scorecard that is not stale, or an internal tool that answers the question without a scavenger hunt.

The temptation is to treat that work as backend maintenance. I think that is usually wrong. If the data is late, lossy, hard to debug, or shaped around a vendor instead of the product, the product experience inherits all of that friction.

The best data systems I have worked on keep the raw material close. Pull from the source, store what actually arrived, make transformations explicit, and leave enough trail to explain weird numbers later. It is not glamorous, but it makes the product calmer.

I also like removing machinery when it stops earning its keep. If a paid integration layer is only managing API access, scheduling jobs, and passing records through, maybe a small local runner plus a cron job is easier to understand and cheaper to operate.

Good plumbing changes the pace of the product team. When the data is legible, people stop arguing with the dashboard and start asking better questions.