Use a single database and RLS + session id to ensure queries already come filtered for that tenant without the need to add "where tenant_id = ?" around the application layer.
It doesn't matter how much experience you have with past estimates if one of the steps in the flow involves a scenario where you just can't estimate it. (Happens a lot when dealing with third parties)
"Critics of estimation" usually do this because managers don't actually know the concept of "estimation" and define your worth and paycheck on this concept. So it's just easier to simplify it to "just random".
Saying that your future estimates will improve based on your last ones, is like saying you have more chances of winning the lottery if you lost some games before.
I know its gonna sound entitled. But even though we are a small company we still process a lot of events from third parties. Temporal cloud pricing is based on number of actions, 2400 bucks would only cover some months in our case.
Well, you just got an user. Love the concept of temporal, but i can't justify the overhead you need with infra to make it work for the upper guys... And the cloud offering is a bit expensive for small companies.
Lets say they have a contract with a company for X months, what would they do after those months? Iterate every video file and remove the old ad? Imagine the scale of this when you have millions of videos and thousands of advertisers
We can't even have a consensus on what "unit" tests really are... Every company i work for has a different meaning for it. Some places consider a test "unit" when all the dependencies are mocked, some places consider a whole feature a "unit".