Somewhere in the first twenty minutes of every kickoff call there is a moment where someone walks me through the stack. It is usually a screen share, occasionally a slide, and the tone is always faintly apologetic, because nobody is ever entirely happy with what they bought. Salesforce or HubSpot. Brevo or Braze. Whichever CRM got chosen three years ago by somebody who has since left the company, whichever sending platform came bundled with it, whichever enrichment vendor happens to be on the invoice this year. And then they ask whether I am comfortable with all of it.
I always say yes. Most of the time I have never opened the thing.
That used to feel like a small dishonesty, and it took me a while to work out why it isn't one. The tool is the part of this job with the shortest shelf life. Platforms get swapped after a bad renewal, or absorbed into something else after an acquisition, or quietly abandoned because the person who championed them moved on and nobody else liked it much. Whatever I might learn about the particular way one vendor handles custom fields is knowledge with an expiry date on it, and none of it travels to the next engagement. Meanwhile there is always somebody on the client's side who knows that interface far better than I ever will, because they are inside it every single day, and me knowing it slightly worse than they do adds precisely nothing to anyone.
What does travel is the way you work. That is the part almost nobody thinks to ask about, and it is the only part I would bother defending.
The questions that do not change
While someone is talking me through their stack, I am quietly running the same checklist I run every time, and it has very little to do with which logos are on the screen.
Can I read all of the data, or only the slice the interface has decided to show me? Can I write back, or is this a one-way mirror? Does the API actually cover the objects I need, at the volume I need them, or are the rate limits low enough that a full sync would take a fortnight, which is the sort of thing you tend to discover in week three rather than week one? What happens to custom fields, which is where most companies quietly hide the thing that actually makes their business work? What does it cost to pull all of it rather than a polite sample?
And underneath all of those, the question I have come to care about more than the rest: if this number turns out to be wrong three months from now, how would anybody find out?
Those questions are identical for a platform I have used for years and one I am seeing for the first time, which is exactly why the platform matters so little. I have watched people who know a system inside out, who can move through it faster than I ever could, build something that looked entirely correct and then quietly stopped being correct, because nobody had thought to ask that last question out loud.
What I actually turn up with
Every engagement ends up taking the same shape, whatever the client happens to run. I put a database I control in the middle of it and pull everything into that, so the data from all those disconnected systems finally sits somewhere I can work on it properly. In my case that means Supabase, and I am not going to dress that up as a considered architectural position. It is Postgres, I know it well, I can have something standing up in an afternoon, and it does not fight me. It is my cutting board.
Everything worth talking about sits around it, and that is the part I have spent years on rather than months. The scripts I reach for on the first morning of a project. The patterns for pulling a complete export out of a system that would rather throttle me than hand it over. The way I structure ingestion so that adding a fifth channel six months in does not mean going back and rewriting the first four. The checks I run before I trust a number, and more to the point, the habit of running them before anybody has thought to ask me whether the number can be trusted. That is the only tool in this job that actually belongs to me, and it is the one I sharpen every day.
Which is what people get wrong when they hear tool-agnostic and assume it means indifferent. I am not remotely indifferent. My opinions just live one layer below the question I was asked.
Where it stops being theoretical
Here is the uncomfortable half of this, and I would rather write it down than pretend it away. The data is very often not all available to you. Full API access, workable rate limits, and the specific objects that matter tend to sit on a plan one or two tiers above the one your client is actually paying for.
That is not vendors being incompetent, and it is worth understanding rather than resenting. Getting your data out is the single largest cost of leaving a platform, so a vendor who makes export cheap and complete is a vendor who has made it easier for customers to walk away from them. Very few are going to price against their own retention, and I suspect I would make the same call in their chair.
What separates finding that out in week one from finding it out in week four is not cleverness, and it is certainly not product knowledge. It is the habit of asking what a system will refuse to give you before anybody has promised a client a date. If the plan they are on does not expose what the project needs, I would far rather say so on day two, while it is still a procurement conversation and nobody has committed to anything, than hand over something quietly thinner than what we agreed and explain the gap afterwards.
So when you are trying to work out whether I can work with your stack, do not send me the list of tools. Send me the API documentation, and tell me which plan you are on. That answers the question you were actually asking, and it is usually the thing that decides the timeline.