Hi Eric! You've built more than half of Clay's 200+ integrations, so I'm curious about the engineering judgment behind that. When you're deciding how to build a new integration or add it into a waterfall, how do you decide the tradeoff between making it flexible and powerful versus keeping it simple enough that someone new to Clay can actually use it without getting overwhelmed?
This is a great question! The answer has actually changed over time. In the beginning, we would actually take each integration provider, and tailor the responses to work better in Clay to match with other providers, so it would be easier to use. So, we’d rename fields, remove the fields that were confusing (i.e. a revenue amount without a currency or cents vs dollars), and then make sure everything was cohesive. However, as we started scaling the number of providers, this was not scalable because the providers themselves would be asked questions about the data and then say: “we don’t provide that field” and it would be a whole mess. So, we made the choice to stay true to the provider to allow things to be more flexible, even if the overhead was a bit more. In terms of using Clay without getting overwhelmed, as we’re building a waterfall, we try to do our best to rank providers to give you the best results for what you need, and that’s going to get better over time as well. Moreover, Sculptor and investing in AI will help bridge the gap between our highly technical power users, and those just coming to Clay with a use-case. The goal is that we’d use our institutional knowledge to help you build effectively.

