# Data tools are getting better. Data teams are still stuck. Four colleagues praised our demo. The fifth reviewer, a system integrator we barely knew, questioned the complexity and the problems we had chosen to solve. We had to reconsider what would make the platform useful to a data team. We were proud of our early demo. Anton and I had spent months building it: orchestration across tools, a scalable Kubernetes cluster, and metadata-driven code generation tied to data contracts. The first four people we showed it to were colleagues from our professional network. They understood the engineering and liked what they saw. In the fifth meeting, a system integrator we barely knew had a different response. We had asked for honest feedback. "Nobody cares about data contracts. It's boring. Business users will fall asleep." "Kubernetes is way too complex. Do you really expect organizations to support this? Only advanced teams use it. And they prefer their own setup." "And you're adding another tool to the stack? Our clients already have too many tools. This makes things more complex, not easier." We drove back mostly in silence. When we started talking, we realized we were more energized than deflated. We still believed in the engineering, but we had presented the parts we found interesting without explaining why a team would want to take responsibility for running them. A scalable cluster was an achievement for us. For the integrator's clients, it was something else to support. The feedback also made us reconsider the contracts. We needed them to describe the data and drive code generation. That did not mean a business user needed to care about the format. We had spent too much of the demo explaining our implementation and too little showing what work it would save. --- The [2026 dbt State of Analytics Engineering report](https://www.getdbt.com/resources/state-of-analytics-engineering-2026) gives some context for that conversation. It surveyed 363 data practitioners and leaders in late 2025 and early 2026. A majority still reported spending most of their time maintaining or organizing datasets, and 83% said increasing trust in data and data teams was important. There was progress too: the share citing integration across sources as a top challenge fell from 35% to 27%. Poor data quality remained the most frequently reported obstacle. That is one vendor's survey, with a particular community of respondents. It cannot tell us what every data team needs. But the maintenance work is familiar: a load fails after a source changes a column type, a pipeline change leaves its documentation out of date, or two reports disagree and someone has to trace both numbers back to their sources. These are legitimate engineering responsibilities. Keeping the data reliable is part of the job, and some of it needs someone who understands the business. The frustrating part is repeatedly doing work whose rules are already known. If the source schema describes a column, why should each downstream project have to reconstruct its type? If a pipeline definition changes, why does someone have to remember which documentation pages to update? Those are more useful questions for our platform than how many tools we can orchestrate. They give us something specific to improve and a way to judge whether the improvement saves a team any effort. --- Earlier this year I met a senior restructuring officer, the kind of person private equity firms call when a portfolio company is in crisis. He described a company that lost 50% of its revenue in a single year following a failed ERP implementation. Several hundred million gone, and the company on the brink. What stayed with me was his account of the leadership team. They had not seen it coming and could not answer basic questions about their own business: which customers were profitable, or what margin each product sold at. I cannot diagnose what failed from that account. The company had systems and data, yet its leaders could not get answers they could use at a critical moment. Buying another tool would have needed a clear explanation of how it helped with that situation. A catalog or an orchestrator can contribute to a reliable answer. Neither removes the need to agree on the meaning of a margin, check how it was calculated, and make it available to the person asking. Our demo had barely addressed that work. We had shown the infrastructure underneath an answer and expected its value to be obvious. --- We are building Amfelt around shared metadata and pipeline definitions because we want to reduce that repeated implementation work. The aim is to describe a source once and use that description to drive its loading, data platform layers, and technical reference. That still leaves choices for a data team to make, including which sources to trust and what a business measure means. We also have to account for the work the platform introduces. A team has to learn it, connect it to existing systems, and investigate it when something fails. The integrator was right to count that cost. Automating a task is useful only if the result takes less effort to operate than the task did before. --- I would give that demo differently now. I would spend less time on the cluster and ask which recurring job the team would most like to stop maintaining. That is where we need to earn our place in their stack. If you have a job like that in mind, we'd like to hear about it: [join the waitlist](/waitlist/).