Show IH: I shipped 12 offline-first CLI dev tools from Burkina Faso — built with heavy AI pairing, install in one command
Hey IH,
I'm a solo founder based in Ouagadougou, Burkina Faso. I build software with heavy AI pairing (Claude) — I work with the model, review the output, and ship. All the code in this pack was built that way, and I'm being upfront about it.
I just shipped Lim@ck DevTools — a pack of 12 single-file shell tools, each solving a real friction point I've hit developing here: slow connections, power cuts that wipe setups, curl | sh scripts I couldn't fully trust, error messages that assumed you speak perfect English.
One command installs the whole menu:
curl -fsSL get.limackcorp.online | sh
The 12 tools:
- peek — shows you what a curl | sh script does before you run it: risk score + dangerous lines. (Heuristic, not a sandbox — honest about limits.)
- devbox — machine setup + offline mode: prep bundles once, deploy on a box with no internet
- sneakersync — git over a USB key, no network — full or delta
- wat — pipe an error in, get a plain-French explanation + the fix (via OpenRouter)
- resurrect — snapshot your dev environment, rebuild it anywhere
- litemirror — one machine = LAN package cache for pip/apt, one download feeds the room
- tunnelforge — expose a local port via Cloudflare, no ngrok account needed
- deadman — uptime monitor + heartbeats, Telegram alerts on state change only
- secrets-doctor — local scan for leaked keys + pre-commit hook, nothing uploaded
- fr — francophone dev assistant in the terminal (OpenRouter)
- oneshot — fresh VPS → app host with Caddy auto-HTTPS
- landrop — share one machine's local Ollama model across the LAN: offline AI for the whole room
The angle isn't "use these instead of better tools." It's: these work when the infrastructure doesn't — slow bandwidth,
no public IP, shared lab machines, French-speaking team.
I ran all 12 through a smoke-test harness and made the whole pack shellcheck-clean (0 warnings) before shipping — a tool you can't run in real conditions isn't finished.
Repo (MIT, everything readable): https://github.com/limack0/limack-devtools
Who this is for: developers in low-bandwidth or constrained environments (West Africa, shared labs, remote sites, air-gapped machines). Also useful anywhere — secrets-doctor, peek, and tunnelforge have no geography.
What I'd value from this community: which of these overlaps with something you already use? And which friction points did I miss that you've hacked around yourself?
All tools AI-paired with Claude, reviewed and pushed by me.
What stood out to me wasn't the tools themselves, but how many of them seem to come from infrastructure constraints rather than feature ideas.
I'm curious whether the bigger opportunity ends up being "offline-first developer tools" or simply "tools built for environments that mainstream products rarely optimize for."
Good way to put it, and honestly it pushed me to actually pick a side instead of hand-waving both.
I think it's the second one. "Offline-first" describes a property a few of these have (devbox, sneakersync, litemirror, relay) — but the actual constraint I kept hitting wasn't "no internet," it was "the internet is unreliable, slow, or metered, and most tooling silently assumes it isn't." That's a wider net than offline. tunnelforge exists because I don't have a stable public IP, not because I'm offline. wat and fr exist because error messages and docs assume fluent English, which isn't an infra problem at all — it's mainstream tooling not optimizing for a non-English-default user. secrets-doctor and peek aren't constrained by my environment either; they exist because I don't fully trust scripts I didn't write, which is a trust gap, not a bandwidth gap.
So if I had to name the opportunity, it's closer to "developer tooling for the assumptions mainstream products bake in by default" — stable broadband, US/EU power grid, English as a given, trusting the supply chain. Offline-first is one visible symptom of that, not the whole shape of it.
Practically this matters for what I build next: if I optimize purely for "works offline," I'd over-index on caching and sync. If I optimize for "environments mainstream tools ignore," the backlog looks different — more about defaults (language, trust, cost-per-byte) than connectivity specifically. I'm leaning toward building from the second framing going forward.
Did you land on this from a similar build, or is it more of an outside-in read on the pattern?
Outside-in.
Interesting response.
I ended up with a few questions after reading it that I think are more useful than my answer to the original question.
Happy to continue by email if you'd like.
This comment was deleted 2 days ago.