Development Environment Bootstrapper (Cross-Platform)

2–4 hours of setup.
Automated down to one command.

Every new machine was the same pain — reinstall tools, reconfigure the shell, hunt down dotfiles, repeat. Doing it once is annoying. Doing it across different distros, on a friend’s machine, on a clean VM — that’s when you stop tolerating it and start automating it.

Why multi-platform

The machines vary — personal Arch setup, a friend’s Mac, a lab machine running Ubuntu or Fedora. The script needed to work on all of them without modification. Detect the OS, pick the right package manager, proceed. One command regardless of what’s underneath.

What it handles

OS detection

macOS · Arch · Fedora · Ubuntu
Picks brewpacmandnf, or apt automatically.

Dotfiles

Symlinked, not copied
Config lives in one repo. Changes propagate everywhere.

Installation

Interactive + idempotent
Pick what to install. Re-run safely — already-installed tools are skipped.

Testing strategy

Cross-platform scripts fail in ways that are hard to predict without running them. The solution: Podman containers. Each supported distro gets a clean container, the script runs, behavior gets verified before anything touches a real machine.

15+

machines actively running it

10–15

real machines tested

<30min

vs 2–4 hours manual

What made this worth building

The 2–4 hour manual setup wasn’t just slow — it had points of failure. A missed dependency, a config that didn’t apply, a font that didn’t render right. Each machine was slightly different from the last. This script eliminates that variance entirely.

The more interesting insight was about workflow compounding. A carefully designed environment — the right tools, configured the right way — makes everything downstream faster. Investing time once to automate setup pays back on every machine you ever touch after that.

What this taught

How operating systems actually differ at the system level — not in theory, but in the specific ways package managers behave, paths resolve differently, and config conventions diverge. Writing a script that handles all of it forces you to understand each one rather than just use it.

Idempotency as a design goal, not an afterthought. A script you can run twice without breaking things is a different class of script than one you run once and hope for the best.

Status & next

Already published. Next: a TUI layer so others can navigate it without touching the script directly — making it genuinely usable beyond just personal use.