Adaeze Ohanyere

Stop sharing the headset. That's the whole problem. One machine gets an over-ear headset, the other gets on-ear or an earbud, and you can tell which one you're wearing without looking.

Then make the mute physical on both. An inline mute button on the cable or a headset that mutes when you flip the boom up means your hand knows what it did. Software mute in a window you can't see is how this happens.

Last bit: only one laptop is ever centred in front of you. The other lives at 45 degrees on the left. Your body learns the geometry within a week.

Add a cheap USB light on the machine that's live if you want belt and braces. Green means this one is the meeting. Costs about the same as lunch.

It isn't a user count question, it's a latency and failure question, and you already crossed the line.

The test I use: does the work need to finish before the user can be told what happened? Sending an email doesn't. Generating an invoice PDF doesn't either, you can show a link that appears when it's ready. Both of those belong out of the request at any scale, including ten users.

The part that matters more than speed is failure. Right now, if your mail provider has a bad thirty seconds, your signup returns a 500 and the user thinks the account wasn't created. With a queue, the account is created and the email retries three times over ten minutes. That difference is worth more than the 900ms.

You do not need a broker for this. If you already have Postgres, a jobs table plus select ... for update skip locked and a small worker loop is about eighty lines and will carry you a very long way.

That's how most people get sold on it. Add a attempts column and a run_after timestamp from day one, retries with a bit of backoff are the whole point.

Honest answer from the other side: for some people it doesn't fade, and that's worth taking seriously rather than pushing through. Two of the four people I know who tried this stopped inside six months, not because they got caught but because they didn't like who they were at 6pm. If you're still at this level of alert in three months, that's information, not failure.

Everyone learns that one the same way. Also do the reverse proxy thing when you have a spare afternoon, it will save you the third-party cookie deprecation conversation entirely.

You've described the cause in your own post without noticing. The dev proxy makes everything same-origin, so the cookie is first-party and the browser is relaxed about it. In production the frontend and the API are different sites, so that cookie is now a third-party cookie and the default SameSite=Lax means it is never attached to a cross-site XHR.

Minimum to make it work as-is:

• SameSite=None; Secure on the cookie, and Secure means real HTTPS on both ends
• credentials: 'include' on every fetch, it is not the default
• Access-Control-Allow-Credentials: true on the API
• Access-Control-Allow-Origin set to your exact frontend origin, because a wildcard is ignored when credentials are involved

Miss any one of those four and you get exactly your symptom, header present, cookie never sent.

The better fix, if you can, is to stop it being cross-site at all. Put the API behind the same hostname on a path, example.com/api, via a reverse proxy or your host's rewrites. Then everything is first-party, none of the above applies, and Safari's tracking prevention stops being your problem in six months.

Don't ask to move a recurring meeting that suits people in another timezone. That request gets declined and then remembered. Ask to be excused from it instead, which is a much smaller thing you're asking for.

Check for a redirect on the preflight too. If your route is /api/things/42 and something normalises a trailing slash with a 301, the browser will not follow a redirect on an OPTIONS preflight, it just fails. Look at the status code in the network tab rather than assuming it's 204.

For a genuinely reactive job I'd go further and block one thing a day, not a week of blocks. One 90 minute protected slot in the morning for the work that only you can do, and the rest of the day is fair game for whatever arrives. I've kept that for three years, which is longer than any full system I ever tried.

Also: stop volunteering at A immediately. Not sabotage, just no new scope. Post-layoff teams have a lot of unowned work floating around and it lands on whoever last said yes.

Run explain (analyze, buffers) on both versions and look at the buffer numbers rather than the timings. You'll see something like 12 shared hits on the fast one and 400,000 on the slow one, and that difference is the whole story. Timings vary with cache state, buffers don't lie.

This is the honest tradeoff. Fewer moving parts beats better parts for most people, and anyone who says otherwise has never watched their own system decay.