On every intake call someone runs through their stack and asks if I am comfortable with it. Salesforce or HubSpot. Brevo or Braze. Whichever CRM they bought three years ago, whichever sending platform came with it, whichever enrichment vendor is on the invoice this year.
I always say yes, and it has almost nothing to do with whether I have used the tool before.
I work headless. I am not in the interface much, and someone on the team will always know it better than I will, because they are in it every day. What I need from a CRM is API access to the records.
So while someone is listing their stack, the questions I am actually working through are these. Can I read all of the data, or only what the interface exposes? Can I write back? Does the API cover the objects I need at the volume I need, or are the rate limits low enough that a full sync takes a week? What happens to custom fields? And what does it cost to pull everything rather than a sample?
If I can get good answers to those, the rest is detail I can pick up in a couple of days.
Where the data lands
Every project ends up with the same setup. The tools differ each time. What does not is that I put a database I control in the middle, and pull everything into it so the data from all those systems sits together.
For me that is Supabase. There is no grand technical case behind it. It is Postgres, I know it well, I can have something running in an afternoon, and it does not get in my way. It is my cutting board. Whatever the client happens to use, the data ends up there before I do anything real with it.
This is what people miss when they hear tool-agnostic and assume I have no opinions. I have a lot of them. They just sit one layer below the question I am being asked.
The tool I actually use
The tools on a client's invoice are rented. They get replaced after a bad renewal, or consolidated after an acquisition. What I learn about the quirks of one vendor's interface has a short shelf life and does not carry over to the next mission.
What does carry over is the set of things I have built for myself. The scripts I reach for on day one. The way I pull a full export without getting throttled. The way I structure ingestion so that adding a fifth channel does not mean rewriting the first four. The checks I run before I trust a number. That is the tool I actually use, and I work on it every day.
The part that is less comfortable
The data is often not all available. Full API access, higher rate limits, and the objects that matter tend to sit on a plan above the one the client is paying for. Sometimes several plans above.
That is not incompetence on the vendor's side. Getting your data out is the main cost of leaving, so a vendor who makes export cheap and complete is making it easier for customers to go elsewhere. Very few of them will price against their own retention.
What it changes for me is practical. "Can we do this" is sometimes a procurement question rather than a technical one, and I need the answer in week one. If a client's plan does not expose what the project requires, I would rather say so immediately than find out in week four and hand over something thinner than what we agreed.
So when you are deciding whether I can work with your stack, the useful thing to send me is the API documentation and your current plan. That tells me more than the list of tools does, and it is usually what determines the timeline.