DEV Community: JackWu

6 Business Questions Every Solo Dev Skips (That Kill Products Before Launch)

JackWu — Sat, 21 Feb 2026 14:23:47 +0000

I spent two months building a macOS tool. Shipped it. Got 23 visitors. Zero paying users.

Not because the code was broken. Not because the design was bad. Because I skipped everything that happens outside the code editor.

Here's the pattern I've watched repeat across dozens of indie products: developer gets an idea, gets excited, starts building, ships after a month, hears crickets, gets confused. The gap is between "idea" and "start building" — at minimum four things get skipped there.

The 4 Things That Get Skipped Before Line 1

1. Does this problem actually exist? Not "do you think it exists" — is someone actively searching for a solution right now?

2. Who already built this? Not just awareness that competitors exist, but a real breakdown of their tech, pricing, and user complaints.

3. Where are your users? Not "on the internet." Specific subreddits, Discord servers, forums, newsletters.

4. Why you? Not feature count. One dimension where you're clearly better.

In a big company, a PM handles this. Product research teams validate it. Solo? All of it lands on you — and developers are wired to jump straight to the code.

My Mistake: Competitive Research After Launch

I built GroAsk — a native macOS menu bar launcher that gets you into Claude Code with a single hotkey (⌥Space). Agent dispatch panel, multi-CLI support, 100% local.

I did competitive research after the product was feature-complete. What I found:

10 direct competitors
The top one (opcode) has 20k+ GitHub stars
Auto-Claude has 12k+ stars with 73 contributors
Even the YC-backed Claudia chose AGPL open source

Every single competitor is free and open source. Not one charges a dollar.

If I'd done this research before writing line 1, my design and pricing strategy would have looked completely different.

But here's where competitive research pays off in a non-obvious way: I noticed something in the tech stacks. Every competitor is built on Electron, Tauri, or pure web tech. Not one is native macOS.

That's a real opening:

Dimension	Electron / Tauri	Native AppKit (GroAsk)
Launch time	1–3 seconds	< 0.3 seconds
Memory	200–500 MB	< 50 MB
System integration	Limited	Menu bar, global hotkeys, native notifications

Lesson: competitive research isn't for talking yourself out of building. It's for finding the dimension where you can actually win.

Pick One North Star Metric

The scariest thing about indie products isn't failure. It's not knowing you're failing.

If you're tracking downloads, DAU, retention, conversion rate, and NPS at the same time — you're tracking nothing. When everything matters, nothing matters.

My approach: one north star metric per stage, everything else is context.

Right now I'm tracking GitHub Stars. Reasons:

Zero friction — no signup, no download required
Unambiguous — the number is the number
Social proof — new visitors lower their guard when they see stars
Real signal — starring means "I think this is useful, might use it later"

Secondary metric: WAU (weekly active users), defined as opened the app 3+ times in the past 7 days. Currently 12.

The stage determines the metric. Cold start: track attention (stars, signups, saves). Growth: track engagement (DAU, retention). Monetization: track revenue (MRR, LTV). One primary metric per stage. Everything else is supporting data.

Distribution Is a Loop, Not a Single Post

Most solo devs think "marketing" means: write a post, share it to a few communities, wait.

I did exactly that. Hit 15+ channels. Then nothing.

What changed it: I started tracking actual referral data. Every download link gets a ?ref=xxx parameter. The site logs where visitors come from.

Two weeks in:

Channel	Visitors	Share
GitHub	34	20%
Google Search	35	20%
X / Twitter	21	13%
Appinn (niche software community)	19	11%
Eleduck (remote work community)	13	8%
W2Solo (indie dev community)	10	6%

Two decisions came directly from this table:

Cut the low-signal channels. LinkedIn brought 1 visitor. Not worth the time.

Double down on X/Twitter. Claude Code users cluster there. 13% from one social platform signals the high-frequency posting strategy is working. Shifted to 3–5 posts per week of Claude Code workflow content.

Distribution isn't a one-shot. It's a feedback loop: post → track → find what works → concentrate there → post again.

Pricing When All Competitors Are Free

Can you charge when everything similar is free?

I spent a while stuck on this. The math that unstuck me:

Claude Code has millions of users globally (conservative estimate). I need 0.01% of them — roughly 900 people — willing to pay $5/month. That's ~$54K/year.

That reframe moves you off "how do I compete with free" and onto "who are the 900 people and what do they need."

Strategy:

Free tier: match the best open-source competitor on core features. Don't hide the good stuff.
Pro tier: things power users actually pay for. Multi-CLI support, advanced monitoring, custom themes.
Don't compete with free. Compete with "not good enough."

Pricing is never really about the number. It's about: who are you creating value for, what is that value worth to them? If your tool saves someone 10 minutes a day, $5/month is not the conversation.

The 6-Question Checklist

Everything above compresses into six questions. Before you write a line of production code, spend half a day writing actual answers:

1. Who am I solving this for, exactly?
Not "developers." "macOS developers who switch between 3+ Claude Code projects daily and lose context every time." The more specific, the more useful.

2. Who already built this? How good is it?
List 5–10 competitors. Tech stack, pricing, user complaints. Find what users are actively complaining about — that's your opening.

3. What's the one dimension I can win on?
Speed? Native feel? Price? Community? Integration depth? Pick one and go deep, don't spread across all of them.

4. How will I know if this is working?
One north star metric, matched to your current stage. Not five metrics — one.

5. Where are my users? How do I reach them?
Name five specific communities. Track referrals after you post. Cut the low-performers within two weeks.

6. What's the business model?
You don't need a final answer on day one, but you need a hypothesis. Freemium? Subscription? One-time? What's your revenue target, and how many paying users does that require?

These questions don't need perfect answers. Writing them down is already 10x better than "I'll figure it out later."

My product is still in cold-start. The answers are still getting revised. But I'm not "ship and pray" anymore.

If you're building something solo right now — open a doc, spend 30 minutes on these six questions. You'll find that a lot of the fuzzy stuff gets concrete fast.

I'm building GroAsk — a native macOS launcher for Claude Code. If you use Claude Code and want to try it, it's free to start.

What's the business question you wish you'd asked before you started building? Drop it in the comments — I'm curious what others have learned the hard way.

20 Days, 20,000 Conversations, 1.2 Billion Tokens: What I Learned from Heavy Claude Code Use

JackWu — Fri, 20 Feb 2026 14:19:34 +0000

I started using Claude Code in November thinking it was just a smarter Cursor. After 20,000 conversations and 1.2 billion tokens — verified by Anthropic as a top 1% user — here's the full retrospective.

1. The Mental Model Shift: From AI Assistant to AI Team

When I first picked up Claude Code, I treated it like an autocomplete tool with better reasoning. A smarter linter. A more accurate Cursor.

That framing was wrong.

After enough usage and conversations with others doing the same, the better mental model clicked: Claude Code is not an AI assistant. It's a capable, low-cost, reliable team.

Not an intern. A team.

2. What 20 Days of Output Actually Looks Like

Claude Code can now carry a product from zero to shipped — independently, end to end. Here's what I built in 20 days:

Product	Stack	Time	Notes
AI ChatBot	Flutter	2 days	Voice input, resume upload, AI interviewer
iOS Launcher App	Native iOS	2 days	—
GroAsk	Native macOS	2 weeks	Claude Code session manager — the tooling behind everything in this post

All three were vibe-coded. No lines written by hand. During the Opus 4.5 era I'd still glance at the code occasionally. By Opus 4.6, I stopped reading it entirely.

GroAsk came out of my own frustration: constantly switching terminals, losing track of which session was doing what, context windows silently filling up with no visibility. I built it to scratch my own itch. More on that below.

3. Beyond Coding: What Else Claude Code Handles

Auto-posting to Twitter — via browser MCP + custom Skills
Article writing and multi-platform distribution — via custom Skills
Product analytics — running against real operational data
Market research — gathering user pain points, validating assumptions

4. My Iteration Loop

Small changes: one sentence to shipped

Describe the change → Claude Code executes → Ship → One-line fix if needed

Large features: structured pipeline

Gather requirements → PRD → Market validation → Tech spec → Execution plan → Build

In practice:

Requirements: personal pain points + community feedback
PRD: describe the raw need, let Claude Code draft the PRD, validate with research
Tech spec: Claude Code writes it, market research reviews it
Execution plan: Claude Code uses TDD + subagents to break down tasks
Build: execute the plan

A 3,000-word PRD → 10,000-word tech spec → 40,000-word execution plan. The AI handles the expansion. I handle the decisions.

The principle that matters most

Product decisions and technical decisions are the human's job. Fully delegating decisions to AI still breaks down on complex tasks — it looks like it works, but the maintenance cost is brutal. Get the design right first.

Break problems into small, concrete tasks. A focused, small prompt outperforms a large, vague one in reliability, speed, and outcome.

5. Techniques That Actually Matter

5.1 Skills: The Highest-Leverage Feature

Core idea: encoding your own workflows.

A Skill has two parts:

Prompt: natural language description of what needs model judgment
Scripts: code for the deterministic parts

Only use prompts where judgment is required. Everything else should be a script.

My regular Skills: atomic commits, auto-build-and-run, pulling operational metrics, posting drafts, writing articles from outlines.

5.2 Subagents: Context Management for Complex Tasks

The built-in Task tool is Claude Code's subagent mechanism. The main session delegates work to internal sessions and only cares about inputs and outputs. This keeps the primary context clean on long-running tasks.

5.3 MCP: Extending What Claude Code Can See

I run 8 MCPs personally, but I'd recommend fewer to start
MCPs consume a lot of raw context — use parameters to expose minimal interfaces
Prefer Rust or Go compiled MCPs over Node — significantly lower memory footprint

5.4 Hooks: The Safety Net

The highest-value hook I've set up: back up anything untracked before Claude Code deletes it.

5.5 The Most Effective Debugging Technique

Write logs to disk. Let Claude Code read the logs and diagnose from there.

This is the most reliable way to resolve bugs — more reliable than anything else I've tried. When you think Claude Code is stuck, try logs. It will surprise you.

6. Long-Term Memory: Making It Stick

Forgetting context across sessions is a real friction point. My solution: layered knowledge files.

Maintain a hierarchical knowledge/ folder. Tell Claude Code to store useful findings there.
Use CLAUDE.md files per sub-project, plus a rules/ directory for principles
The result: a local long-term memory that gets better the more you use it

7. Context Management: The Biggest Performance Variable

Strategy	Why
Load MCPs on-demand	Expose minimal interfaces via parameters
Layer CLAUDE.md by scope	Avoid information overload
Hard limit at 200k tokens	Switch sessions before you hit this
Never compress context	Open a new session instead
Monitor in real time	Know what each session is consuming

I keep context under 200k (roughly 20% of the 1M window). The difference between a fresh session and one near the limit is like the difference between a colleague at 9am versus 2am — technically still working, but the quality has dropped.

The "monitor in real time" row is the one most people skip. You keep going, context quietly fills up, and response quality drops off a cliff before you notice. That's actually the primary reason I built GroAsk — a menu bar panel that shows each Claude Code terminal's context usage, current status, and queue at a glance. No more switching terminals to check.

8. Multi-Session: Stop Watching One Window

Running a single Claude Code process at a time is leaving most of the throughput on the table.

Comfortable baseline: 2–3 parallel sessions
High-output mode: 5–10 sessions
Only actively manage sessions waiting for input; let the others run

The practical problem: once you're running 5+ terminals, just finding "which session is waiting for me" becomes its own overhead. My current setup uses GroAsk's dispatch panel — all Claude Code terminals in one view, with status (running / waiting / context usage) visible without switching windows. ⌥Space opens the panel, one click jumps to the right terminal.

If you're running multiple sessions regularly: groask.com

9. Where the Model Hits Its Limits

The one thing models can't do well: genuinely novel work.

When there's no training data to draw from — when you're building something that hasn't been built before — the model is guessing. That's where human creativity and judgment still matter. Know where that line is.

10. Three Takeaways

Claude Code is not an AI assistant. It's an AI team. Manage it like one.
Decisions are your job. Product calls, architecture calls, novel problems — those stay with you.
Engineer your AI usage. Skills encode workflows. Subagents manage complexity. Knowledge files build memory. Context discipline keeps quality high.

I use Claude Code daily to build GroAsk — a macOS menu bar launcher that opens any AI with ⌥Space and monitors all Claude Code terminal sessions in one panel. If you're running Claude Code heavily, it's worth a look.

Automating 4 macOS Terminals for Claude Code: AppleScript, Ghostty's `-e` Trap, and Warp's Missing API

JackWu — Sun, 15 Feb 2026 15:11:34 +0000

I launch Claude Code 30+ times a day. The workflow always looks like this:

cd ~/Projects/my-app
claude "fix the login bug"

# switch project
cd ~/Projects/api-server
claude "add rate limiting"

# switch again...

Four steps every time. Open terminal, cd, type command, wait. Multiply by 30 and you've burned 600 keystrokes on navigation alone.

I wanted a single hotkey that takes a prompt and launches Claude Code in the right directory. So I built GroAsk -- a macOS menu bar launcher. Press Option+Space, type your prompt, hit Enter. Terminal opens, cd's to the project, Claude Code starts with your prompt already loaded.

The hard part wasn't the launcher UI. It was making it work across Terminal.app, iTerm2, Ghostty, and Warp -- because they all automate differently, and some barely automate at all.

This post covers the technical implementation of each terminal integration, the PATH detection problem in GUI apps, and the one-click CLI installer with dependency chain resolution.

The Problem: 4 Terminals, 4 Different Automation Models

Most Claude Code tools assume Terminal.app. But developers use different terminals. iTerm2 is the most popular third-party option. Ghostty (by Mitchell Hashimoto) is gaining traction fast. Warp has a dedicated following.

Supporting "just Terminal.app" means excluding a large chunk of your users. So I implemented all four.

Here's how they differ:

Terminal	Automation Method	Quirks
Terminal.app	AppleScript `do script`	Full scripting dictionary, straightforward
iTerm2	AppleScript `write text`	Full scripting dictionary, different commands
Ghostty	Clipboard paste via System Events	No AppleScript dictionary, requires Accessibility permission
Warp	Clipboard paste via System Events	No programmatic API at all, requires Accessibility permission

Let's walk through each.

Terminal.app: The Baseline

Terminal.app has a complete AppleScript dictionary. You can create windows, run commands, and control tabs programmatically.

tell application "Terminal"
    activate
    do script "cd ~/Projects/my-app && claude \"fix the login bug\""
end tell

One catch: if Terminal.app isn't running yet, there's no window to target. You need to wait for the initial window to appear:

set wasRunning to application "Terminal" is running
tell application "Terminal"
    activate
    if wasRunning then
        do script "cd ~/Projects/my-app && claude \"fix the bug\""
    else
        -- Wait for the default window to spawn
        repeat 50 times
            if (count of windows) > 0 then exit repeat
            delay 0.1
        end repeat
        if (count of windows) > 0 then
            do script "cd ~/Projects/my-app && claude \"fix the bug\"" in front window
        else
            do script "cd ~/Projects/my-app && claude \"fix the bug\""
        end if
    end if
end tell

This avoids opening a second tab when Terminal launches for the first time -- the initial blank window already exists, so we execute into it.

I also added an osascript subprocess fallback. NSAppleScript can fail silently due to TCC permission issues on newer macOS versions, but spawning /usr/bin/osascript as a child process sometimes bypasses the restriction.

iTerm2: Similar But Different Dictionary

iTerm2 also has a full AppleScript dictionary, but the commands are different. Instead of do script, you use create window with default profile and write text:

tell application id "com.googlecode.iterm2"
    activate
    create window with default profile
    tell current session of current window
        write text "cd ~/Projects/my-app && claude \"fix the bug\""
    end tell
end tell

Note the use of bundle ID (com.googlecode.iterm2) instead of the app name. Some users have the app named "iTerm" and others "iTerm2" -- the bundle ID is stable across installations.

The write text approach has a benefit: the shell stays alive after the command runs. With Terminal.app's do script, the behavior is similar, but write text is more predictable for interactive tools like Claude Code that keep running.

Ghostty: The Clipboard Paste Workaround

Ghostty is where things get interesting. It's a relatively new terminal by Mitchell Hashimoto (of HashiCorp fame). It has no AppleScript dictionary.

Ghostty does support a -e flag for executing commands:

open -na Ghostty --args -e "claude \"fix the bug\""

But -e replaces the shell. It doesn't load .zshrc or .bashrc, which means your PATH, aliases, and version manager initialization (nvm, fnm, etc.) are all missing. Claude Code itself likely won't be found.

You can work around this by wrapping in a login shell:

open -na Ghostty --args -e bash -l -c "cd ~/Projects/my-app && claude \"fix the bug\""

But in practice, this still had edge cases -- particularly with how Ghostty handles argument quoting and process lifecycle.

The approach I settled on: clipboard paste via System Events. It requires macOS Accessibility permission, but it's reliable:

-- First, put the command in the clipboard (done in Swift before this script runs)
set wasRunning to application id "com.mitchellh.ghostty" is running
tell application id "com.mitchellh.ghostty" to activate
tell application "System Events"
    tell (first process whose bundle identifier is "com.mitchellh.ghostty")
        if wasRunning then
            delay 0.3
            keystroke "n" using command down  -- new window
            delay 0.5
        else
            delay 1.5  -- wait for first launch
        end if
        keystroke "v" using command down  -- paste from clipboard
        delay 0.1
        keystroke return
    end tell
end tell

The Swift side saves the original clipboard contents, writes the command, executes the AppleScript, then restores the clipboard after a 3-second delay (enough time for the terminal to process the paste).

Why clipboard paste instead of keystroke character-by-character? Because keystroke goes through macOS's input method system. If the user has a CJK input method active, the command gets garbled. Cmd+V bypasses input methods entirely.

Warp: No API, Period

Warp is a Rust-based modern terminal. It has no AppleScript dictionary, no -e flag equivalent, and no documented programmatic API.

I initially tried its Launch Configuration feature -- YAML files that define startup commands, triggered via URI scheme:

# ~/.warp/launch_configurations/groask.yaml
---
name: groask
commands:
  - exec: "cd ~/Projects/my-app && claude \"fix the bug\""

Then trigger with warp://action/launch?config=groask. This works, but writing a temp file for every launch felt fragile, and the YAML parsing had quoting issues with complex prompts.

The final implementation uses the same clipboard paste approach as Ghostty, but opens a new tab (Cmd+T) instead of a new window:

set wasRunning to application id "dev.warp.Warp-Stable" is running
tell application id "dev.warp.Warp-Stable" to activate
tell application "System Events"
    tell process "Warp"
        if wasRunning then
            delay 0.3
            keystroke "t" using command down  -- new tab
            delay 0.5
        else
            delay 1.5
        end if
        keystroke "v" using command down
        delay 0.1
        keystroke return
    end tell
end tell

Both Ghostty and Warp require the user to grant Accessibility permission to GroAsk. On first attempt, the app detects AXIsProcessTrusted() == false and shows a dialog pointing the user to System Settings.

The PATH Problem in GUI Apps

Here's a problem most terminal-based tools don't face: a macOS GUI app launched from Finder or Spotlight doesn't inherit your shell's PATH.

When you open Terminal and type which claude, it finds ~/.local/bin/claude because your .zshrc added that directory to PATH. But a .app bundle launched via LaunchServices gets a minimal PATH -- typically just /usr/bin:/bin:/usr/sbin:/sbin.

This means when GroAsk tries to check if Claude Code is installed, which claude or command -v claude would fail even though the tool is perfectly usable from a terminal.

My solution has two layers:

Layer 1: Read the user's actual shell PATH

let marker = "__GROASK__"
let shell = ProcessInfo.processInfo.environment["SHELL"] ?? "/bin/zsh"
let process = Process()
process.executableURL = URL(fileURLWithPath: shell)
process.arguments = ["-i", "-l", "-c", "printf '\(marker)%s' \"$PATH\""]

Launch a login shell subprocess and ask it what PATH looks like. The printf with a marker is critical -- tools like conda, pyenv, and some version managers print extra output during shell initialization. The marker lets me find where the actual PATH value starts and ignore everything before it.

Layer 2: File system scanning as fallback

private static func discoverPaths(home: String) -> [String] {
    var paths = [
        "\(home)/.local/bin",      // Claude Code, CodeBuddy, Kimi Code
        "\(home)/.npm-global/bin", // npm global prefix
        "\(home)/.volta/bin",      // Volta
        "\(home)/.cargo/bin",      // Rust / Cargo
        "\(home)/.bun/bin",        // Bun
        "\(home)/.mise/shims",     // mise
        "/opt/homebrew/bin",       // Homebrew (Apple Silicon)
        "/usr/local/bin",          // Homebrew (Intel) / system
    ]

    // Scan nvm versions: ~/.nvm/versions/node/v<version>/bin
    let nvmBase = "\(home)/.nvm/versions/node"
    if let versions = try? FileManager.default.contentsOfDirectory(atPath: nvmBase) {
        for v in versions where v.hasPrefix("v") {
            paths.append("\(nvmBase)/\(v)/bin")
        }
    }

    // Scan fnm versions (macOS and Linux paths)
    for fnmBase in [
        "\(home)/Library/Application Support/fnm/node-versions",
        "\(home)/.local/share/fnm/node-versions",
    ] {
        if let versions = try? FileManager.default.contentsOfDirectory(atPath: fnmBase) {
            for v in versions where v.hasPrefix("v") {
                paths.append("\(fnmBase)/\(v)/installation/bin")
            }
        }
    }

    return paths
}

This scans known installation directories directly on the filesystem. No subprocess needed, no shell rc loaded. It catches tools installed via nvm, fnm, Volta, Homebrew, Cargo, mise, and the standard ~/.local/bin location.

The two layers merge: shell PATH takes priority (preserves user's ordering), filesystem scan fills in anything the shell missed.

Smart PATH injection

When launching a command in a new terminal window, that window loads the user's shell rc files. So if claude is in a directory that's already in the shell's PATH, we don't need to inject anything -- it'll just work.

But if we found claude via filesystem scanning in a directory not in the shell's PATH (e.g., an unusual nvm version), we prepend an export PATH= to the command:

let pathPrefix: String
if let dir = searchPaths.first(where: {
    FileManager.default.isExecutableFile(atPath: "\($0)/\(command)")
}), !shellNativePaths.contains(dir) {
    pathPrefix = "export PATH=\"\(dir):$PATH\" && "
} else {
    pathPrefix = ""
}
let fullCommand = "\(pathPrefix)cd \"\(safeDir)\" && \(command) \"\(cleanPrompt)\""

This avoids polluting the terminal session with unnecessary PATH modifications while ensuring the command always resolves.

One-Click CLI Installation with Dependency Chains

The last piece: installing CLI tools without touching the terminal.

Some tools have simple curl installers:

# Claude Code
curl -fsSL https://claude.ai/install.sh | bash

# CodeBuddy
curl -fsSL https://copilot.tencent.com/cli/install.sh | bash

Others need npm:

# Gemini CLI
npm install -g @google/gemini-cli

# Codex
npm install -g @openai/codex

The problem: if the user doesn't have npm, they need Node.js. If they don't have Node.js, they need a version manager. That's three installations before you can even start.

GroAsk handles the full dependency chain:

Check if npm exists -> if yes, run npm install -g @google/gemini-cli
No npm? Check if fnm exists -> if yes, run fnm install --lts && npm install -g @google/gemini-cli
No fnm either? Run the full chain: install fnm -> install Node.js -> install the CLI tool

All in one click. No sudo, no Homebrew, no Xcode Command Line Tools required.

After triggering the install, the app polls every 2 seconds using command -v through the user's login shell:

static func isCommandAvailableViaShell(_ command: String) -> Bool {
    guard command.allSatisfy({
        $0.isLetter || $0.isNumber || $0 == "-" || $0 == "_"
    }) else { return false }  // prevent command injection

    let shell = ProcessInfo.processInfo.environment["SHELL"] ?? "/bin/zsh"
    let process = Process()
    process.executableURL = URL(fileURLWithPath: shell)
    process.arguments = ["-i", "-l", "-c", "command -v \(command)"]
    // ...
    return process.terminationStatus == 0
}

The poll runs through a full login shell (-i -l) so it picks up PATH changes from the installation. 3-minute timeout, then it stops. As soon as the tool is detected, the UI updates from "installing" to "ready."

The Resulting Architecture

⌥Space pressed
    |
    v
Launcher UI (prompt input)
    |
    v
Router.dispatch(channel, prompt)
    |
    +--- Web AI? --> WebManager (Chrome AppleScript + JS injection)
    |
    +--- CLI AI? --> TerminalBridge.execute()
                        |
                        +-- Resolve working directory
                        |     (Finder path / alias / default)
                        |
                        +-- Find command binary
                        |     (shell PATH + filesystem scan)
                        |
                        +-- Build command string
                        |     (PATH prefix if needed)
                        |
                        +-- Dispatch to terminal
                              |
                              +-- Terminal.app: AppleScript do script
                              +-- iTerm2: AppleScript write text
                              +-- Ghostty: Clipboard paste + System Events
                              +-- Warp: Clipboard paste + System Events

The whole app is 5,600 lines of Swift (pure AppKit, no SwiftUI App framework, no Electron) + 1,200 lines for the server (Cloudflare Workers for license validation). Memory usage stays under 30MB.

Numbers

6 CLI AIs supported: Claude Code, Gemini CLI, Codex, CodeBuddy, Kimi Code, Qwen Code
4 Web AIs: ChatGPT, Claude, Gemini, Monica
4 terminal implementations
190 commits, 49% co-authored with Claude Code
14 days from first line of code to launch
Free and open source

Comparison with Existing Tools

Capability	Claude Code Now	Raycast Plugin	GroAsk
Launch with prompt	No	No	Yes -- prompt goes straight to the agent
Multi-terminal	Terminal.app only	Terminal/Alacritty/Ghostty/Warp	Terminal/iTerm2/Ghostty/Warp
GUI install	No	No	One-click with dependency resolution
Multi-AI	Claude Code only	Claude Code only	6 CLI + 4 Web AI
Text selection send	No	No	Select text -> hotkey -> sent
PATH auto-detection	No	No	Shell PATH + filesystem scan

Not knocking the existing tools -- they solve real problems. GroAsk just goes further: it's not only a Claude Code launcher, it's a bridge to all your AIs.

If you want to try it: groask.com

It's free, open source, and runs entirely on your machine. No data leaves your Mac -- GroAsk is a local bridge between your keyboard and whatever AI you're talking to.

If you find it useful, a star on GitHub helps more than you'd think for a solo dev project.

I was switching browser tabs 50+ times a day to talk to AI. Here's how I fixed it.

JackWu — Fri, 13 Feb 2026 18:25:07 +0000

I counted yesterday: 47 times hunting Chrome tabs for the right AI. 37 times typing cd in terminal to start Claude Code. That's 84 context switches — each one just a few seconds, but enough to derail a train of thought.

So I built GroAsk — a macOS menu bar app that puts all your AIs behind one hotkey.

The problem

Web AI friction: I'm subscribed to ChatGPT, Claude, Gemini, and more. Every time I need one: switch to Chrome → find the tab → navigate → start chatting. As a developer, my time is split across IDE, terminal, docs. Context-switching to the browser every time kills flow.

Claude Code friction: Best coding AI I've used, but the launch sequence is: open terminal → cd to project → type claude. I have dozens of projects. I can't remember those paths. cd, cd, cd — dozens of times a day.

What GroAsk does

Press ⌥Space from anywhere. A launcher pops up. Type your question, hit Enter. Done.

One hotkey, all AIs. Tab switches between ChatGPT, Claude, Gemini, DeepSeek, and others.
Select text + hotkey = instant query. Highlight text in your editor, press the hotkey, it goes straight to your selected AI.
Claude Code without cd. Pick a project folder from the launcher, Claude Code opens right there.
100% local. GroAsk uses AppleScript to bridge your local browser and terminal. No data proxied, nothing stored.

The build

Native Swift + AppKit (not Electron). ~30MB RAM. Two weeks, solo, with Claude Code as co-pilot.

The web AI channel works by injecting JavaScript into Chrome tabs via AppleScript — each AI site has its own injection script that adapts to the DOM. These scripts update from the server, so when ChatGPT changes their interface, I push a fix without shipping a new app version.

The CLI channel detects your local terminal (Terminal.app or iTerm2), constructs the cd + claude command, and executes it via AppleScript.

Who it's for

Heavy AI users who talk to multiple AIs daily and want zero friction between thought and query.
Claude Code newcomers who want a graphical launcher instead of memorizing terminal paths.

Free to use. macOS only.

Free, under 5MB download, no signup: groask.com

How do you manage your AI workflow? Still tab-hunting, or have you found a better way? Would love to hear in the comments.

I Built a macOS Menu Bar App That Sends Text to Any AI in 2 Seconds

JackWu — Sat, 07 Feb 2026 15:08:03 +0000

I kept switching between AI tabs all day — Claude for code reviews, ChatGPT for API lookups, Gemini for translations. The constant copy-paste-switch loop was killing my flow, so I built something to fix it.

What is GroAsk?

GroAsk is a native macOS menu bar app. Press ⌥Space, type your question, Tab to pick an AI, hit Enter. The question gets sent to the AI's website automatically. The whole thing takes under 2 seconds.

Features I Use the Most

Select & Ask

Select any text on screen — error messages, code snippets, paragraphs — hit the shortcut, and it goes straight to the AI. No copy-paste needed.

Claude Code GUI

Launch Claude Code from anywhere without opening Terminal. It auto-detects your project directory. If you use Claude Code daily, this alone is worth it.

Image Questions

Cmd+V to paste a screenshot and ask the AI about it. Great for asking "how do I implement this layout?" from a design mockup.

Silent Mode

Hold Option when submitting. The question gets sent but your focus stays where it is — keep coding while the AI thinks.

How It Works

Built with Swift + SwiftUI, native and lightweight (~30MB RAM). It uses Chrome AppleScript to auto-fill and submit questions on AI websites.

The clever part: when AI websites update their UI (which happens often), the injection scripts update from the server automatically — no app update needed.

If the primary method fails, it gracefully degrades to clipboard mode (copies the question so you can paste it manually).

Free vs Pro

Free includes 4 channels: ChatGPT, Gemini, DeepSeek, Kimi — enough for daily use.

Pro unlocks Claude, Claude Code, and the productivity features above (Select & Ask, image upload, silent mode).