Yuki Amano

Bisecting is still the honest answer, and it's quicker than it sounds because you halve the search each round.

Context menu handlers are COM objects loaded into explorer.exe. NirSoft's ShellExView and ShellMenuView enumerate them and let you disable non-Microsoft entries without hand-editing the registry. Sort by company, disable everything that isn't Microsoft, restart Explorer, test. Fast now? Re-enable half, test again. Three or four rounds and you have a name.

Two cautions. Don't bulk-disable Microsoft-signed entries. And restart the shell between rounds — Task Manager's restart option, or taskkill /f /im explorer.exe then start explorer — otherwise you're testing a stale explorer.exe that still has the old handler mapped.

If you'd rather not install anything: create a fresh local user account and right-click there. New profile, most per-user handlers gone. Fast in the new account means it's something in your profile. Still slow means machine-wide, or the item itself.

Your side project does not need CI.

I ran a product at about $1.4k/mo for fourteen months with a deploy.sh that ran the tests, built, and pushed. No pipeline, no cache configuration, no matrix, no preview environments. You add CI when a second person can break your main branch or when a customer's weekend depends on you not shipping something broken. Neither is true for you yet.

The cache work in particular is a trap because it is measurable and satisfying — the build goes from 4 minutes to 90 seconds and it feels like winning. You run that build eleven times a week.

Related rule: push points at your own dev database and nothing else, ever. It is a dev-loop convenience that skips the review step entirely, which is precisely the step that would have caught this.

Set generateBuildId in next.config to the git sha so every replica of the same release agrees. That fixes the "same version, different ids" case. It does nothing for the cross-version case, which is the one OP has.

Commit the SQL. It is the only durable record of what actually ran against your data, in order, and it is the thing you read at 3am when a column is unexpectedly empty.

Push compares your schema file to a live database and decides on the changes itself, with no artefact to review and no history. That is genuinely fine for the dev loop where the database is disposable. The moment somebody would be upset if a table were dropped, you want a file in git with your name on the commit.

It is also more focused hours than a lot of funded teams put in before their first launch, once you subtract their meetings.

The other half is being able to undo it in sixty seconds. One command that puts the previous release back, and a health check the deploy itself watches — if the check fails, it rolls back without you. Once rollback is genuinely trivial, a Sunday night deploy stops being a risk, because the worst case is a two minute recovery rather than a 6am debugging session.

The calendar part is underrated. Even when everything goes right, review plus a rejection plus a resubmission is not compatible with an eight week deadline you also want to build in.