jerry@homelab:~/docs$ cat decisions.md
Not Pursued: What I Said No To, and Why
Not every tool I evaluate makes it in. Saying no on purpose -- and writing down why -- is as much a part of running this homelab as anything that actually shipped. A few of the bigger ones:
Built, Then Fully Torn Down: Donetick + Apprise
Before task-bot existed, I tried wiring up Donetick (a self-hosted task manager) with Apprise as the bridge to Signal notifications. The notification leg actually worked cleanly once I got the phone-number formatting and timeout settings right. The blocker was upstream: Donetick's own per-task reminder pipeline failed with an internal error building the notification batch -- confirmed as matching two already-open, unresolved issues in Donetick's own GitHub repo, not anything specific to my setup.
I considered a workaround -- a background poller hitting Donetick's own API for due tasks, sidestepping its broken notification builder entirely -- and explicitly declined to build it. Maintaining a permanent patch for a feature that's supposed to just work, one an upstream update could silently break again, wasn't worth it. Both stacks, their proxy config, DNS records, and backup scope entries were fully removed rather than left half-working. task-bot exists specifically because it owns its entire pipeline instead of depending on someone else's -- there's no upstream bug to wait on, at the cost of maintaining every integration myself.
Evaluated and Declined
- Nextcloud -- no ongoing need for it in this environment. Compose files exist from earlier exploration but aren't a live plan.
- Pangolin as a Tailscale replacement -- would require its own public-facing VPS and re-architecting the entire "nothing exposed" premise this whole project is built around, for a problem that doesn't actually exist here. The one deliberate public-exposure exception this project already has (see Architecture) covers the one case where it's genuinely needed, without touching that principle anywhere else.
- Self-hosted local LLM (Ollama) -- evaluated for the secondary server. Not in the same tier as a hosted model for the kind of layered technical debugging this project involves, and no other concrete use case currently justifies the hardware.
- n8n as a general automation layer -- declined. No concrete recurring cross-service task currently exists that plain bash scripts don't already handle more simply, with far less running infrastructure to patch and back up. Revisit only if a real, specific, recurring need shows up -- "it might be useful someday" isn't a reason on its own.
- Actual Budget in task-bot (via the
actual-http-apicommunity wrapper) -- built, deployed, then removed. The wrapper only supports Actual's legacy single-server-password auth, with no per-user login concept, which is fundamentally incompatible with the multi-user OIDC mode required once real SSO was set up for it. Rather than compromise the SSO setup for one Signal convenience feature, only task-bot's!budgetcommand and the wrapper container were removed -- Actual Budget itself stays on Badlands with its OIDC login intact.
The pattern across all of these: the deciding question is never "could this work," it's "does this replace something with strictly less operational complexity for what I actually need." A tool that adds a second point of failure, a second auth system, or a permanent workaround for someone else's open bug has to earn its place -- and if it can't, walking away from work already done is the right call, not a sunk cost.
jerry@homelab:~/docs$ █
cd ..