Every i3+tmux+vim user has the same scar: a 400-line dotfile graveyard, three prefix keys colliding, and an afternoon lost every time they switch machines. HN threads on this go back years with no durable answer — just forks of forks of single-layer plugins. The pain is real and constantly re-litigated.
The market is small but legible: ~75k serious Linux power users, and at 2% capture × $12/mo that's ~$216k ARR. Not a unicorn — a tight, profitable indie wedge if it lands.
The gap is specific. tmux-tilish, vim-i3wm-tmux-navigator, and a dozen dotfile repos each solve one slice. Nobody ships a single source-of-truth config that generates all three layers with conflict detection. That's our wedge: codegen + collision detection + onboarding, not another plugin.
I'll be honest about the risks. This crowd is ideologically OSS, and the problem is one-time setup, not recurring pain — churn could be brutal and the loudest users will demand we drop the paywall. Operator edge here is near zero; I'm not pretending otherwise.
The test is cheap: 14 days, ~$400 in landing page + plugin polish, unify 5 nav actions across vim+tmux. Kill if <8 sign-ups by day 7, or 10 sign-ups with $0 paid in 30 days post-trial (then we know it's OSS-only and walk). Reversible, small, fast.
Let me spend two weeks and $400 to find out if anyone in this tribe will actually pay. If not, we kill it clean.
The detail behind the pitch
Problem
Software developers using i3/tmux/vim are overwhelmed by managing dozens of keybinds across window managers, terminal multiplexers, and editors, with inconsistent navigation paradigms causing cognitive overload.
Proposed solution
Build a unified keybind abstraction layer that maps a single consistent navigation scheme across i3, tmux, and vim, with smart prefix detection to reduce total keybind count.
Target market
~50k–100k Linux power users (developers, sysadmins, academics) paying $10–50/mo for productivity tools; addressable via indie subscription or sponsorware.
First test
Create a 14-day free trial plugin for vim + tmux that unifies 5 core navigation actions (move, resize, switch, hide, restore) under a single keybind prefix; measure: >10 sign-ups, >5 users activating all 5 actions, NPS >7.
Kill criteria
<8 sign-ups by day 7 AND <3 users completing all 5 navigation actions by day 14 → kill; OR ≥10 sign-ups but $0 paid conversion within 30 days of trial end → kill monetization thesis and pivot to pure OSS; OR day-14 NPS <5 with >2 users explicitly citing 'broke my existing config' → kill current onboarding approach within 72 hours or kill product
Incumbents: tmux-tilish (GitHub plugin, free/OSS), vim-i3wm-tmux-navigator (GitHub plugin, free/OSS), vi3 (GitHub config layer, free/OSS), i3-tmux (Go-based replacement, free/OSS), erikw/vim-keybindings-everywhere (curated list/guide, free), Manual dotfile configs shared on GitHub/HN
Pricing: free (all known solutions are OSS/dotfiles); no paid product identified in this space
Saturation: low
Wedge: Provide the first interactive, installable abstraction layer with conflict detection and a single source-of-truth config that auto-generates i3, tmux, and vim keybind configs — eliminating dotfile stitching entirely.
User complaints: No single tool covers all three layers (i3 + tmux + vim) end-to-end — users must stitch together multiple plugins and configs manually; Prefix key conflicts between i3 mod key, tmux prefix (Ctrl-b/a), and vim leader cause constant collision requiring per-user trial-and-error; Existing solutions are config snippets or single-layer plugins, not an abstraction layer — users still must hand-edit multiple dotfiles; Navigation between i3 windows and vim splits requires a bespoke plugin (vim-i3wm-tmux-navigator) that breaks without careful coordination; No GUI, no conflict detection, no onboarding — the HN thread shows users spending hours on this manually with no durable answer
Notes: The problem is real and well-documented (HN threads, multiple GitHub repos attacking partial solutions) but zero paid/commercial products exist — the space is entirely OSS dotfiles and single-layer plugins. The closest thing is tmux-tilish (maps i3 binds into tmux) and vim-i3wm-tmux-navigator (cross-boundary pane navigation), but neither provides a unified abstraction or config generation. The TAM is small (~50k–100k power users) and monetization via sponsorware/$10–20/mo is plausible but ceiling is low. The wedge is strong precisely because every existing solution requires deep manual expertise — a productized layer with conflict detection and codegen fills a genuine unserved gap.
Skeptic + judge rationale
Death modes:
- The target users are ideologically allergic to paying for tooling that 'should be free' — HN/Reddit power users publicly shame the $10/mo ask, the product gets forked on day 3, and sign-ups plateau at 12 total with 0 paid conversions because the entire community norm is OSS dotfiles and sponsorware guilt-trips the founder into dropping the paywall
- The 14-day trial collapses because onboarding requires users to surrender their existing dotfiles to an unfamiliar config generator — the first 10 sign-ups spend >2 hours debugging edge cases (Arch vs Ubuntu keybind conflicts, Neovim vs Vim API differences, Wayland vs X11 i3 variants), post angry GitHub issues, and NPS comes back at 3.2 because the tool breaks their existing setup before it fixes anything
- Sales cycle is effectively zero but so is retention: the product solves a one-time setup problem, not an ongoing pain — users configure it once, it works, they cancel after month 1 (or never upgrade from free trial) because there is no recurring value delivery loop, resulting in <$200 MRR at day 90 with churn rate >80% on the handful who paid
# Judge rationale (score=71.0)
Wins on capital (pure software, near-zero infra), low human intervention (plugin distribution, no support calls if onboarding works), and a clean wedge in an underserved niche with documented pain. Loses heavily on ARPU/recurring: target audience is ideologically OSS-allergic to paid tooling, and the problem is one-time setup not ongoing pain — high churn risk drops recurring score. Market is real but small (~100k buyers, fraction will pay), and defensibility is near-zero since the entire category is forkable OSS. Borderline bet — score is inflated by low cost-to-test, but the monetization thesis is the actual fragile leg.