Has anyone solved this with tooling or is it an "experience thumbsuck"? What is your method?
I would always try to get a "times and material" agreement, where you are just paid by the hour and estimations are only necessary for rough scheduling and are not bound to your paycheck. This of course implies a certain level of trust that you need to have with your clients. Often this is the case on longer term /regular engagements.
If you need to bid / pitch to a new client you might be forced into a "fixed price" offer for a certain scope. Best to avoid but if you cant I would try to explicitly have some form agreement that allows for some form of re-estimation, e.g. if some explicit (or implicit) assumptions dont hold to be true.
On the matter of estimations: I would try to avoid single-person, one-point estimations (e.g. "3.5 days!") and would try to aim for a three-point or range estimation with some confidence levels (e.g. "best case 1.5 days if all assumptions hold; 3-5 days if we encounter some unknown unknowns, 6-12 days if we totally missed something in the requirements and spec"). Best try to partner up with somebody to get a second opinion about assumptions and risk.
The most solid projections (not estimations) I have seen, were by stable teams who just counted their work-item throughput and learned to be good at item sizing.
They also have online classes with the same content.
If you do that you will be better than 80% of devs at estimating.
After that read about Montecarlo simulation on software projects.
1) I charge $2k and need 5 days to do a Stripe integration 2) You need 1 day and charge $1k
Many factors are at play, for instance availability and experience I presume. Would it be beneficial for us to go to a crowsourced chart and lookup the average integration time for Stripe based on 100's of votes? It seems to be quite open information in other engineering faculties.