Works on My Machine: How Small Teams Get Reproducible Dev Environments Without a Platform Team

Byadmin

Works on My Machine: How Small Teams Get Reproducible Dev Environments Without a Platform Team

“Works on my machine” is the most expensive sentence in small-team software development. It usually means the code is fine and the environment is not. The code works on your laptop because of the dotfiles you tuned three years ago, the aliases you never wrote down, the Docker cleanup you run by muscle memory. Your teammate’s machine has none of that. So the bug report becomes a debugging session, the debugging session becomes a setup session, and the setup session eats the afternoon.

Big companies solve this with a platform team that builds and owns the development environment. Small teams do not have that luxury. You are the platform team. The good news: with a scaffolder and a starter pack, you can get most of the reproducibility benefit without building any platform infrastructure.

Why environments drift

Environment drift is the slow divergence between what your machine actually does and what the rest of the team assumes it does. It starts small: you upgraded Node, they are still on the old LTS. You added a git-sync alias to your shell, they type the same five commands by hand. You pruned your Docker images last week, they are running out of disk and do not know why.

Each difference is tiny. Collectively they guarantee that “it works on my machine” is true for everyone and false for the team. The fix is not discipline — it is making the environment reproducible by construction, so there is nothing to drift.

Two questions every environment answers

Every developer environment is really an answer to two questions:

  1. What is the project structure? Folder layout, Dockerfile, docker-compose services, CI/CD pipeline, test framework, linter presets, environment files, Makefile.
  2. What is my environment? Shell dotfiles, aliases, Git shortcuts, Docker housekeeping, project init scripts.

If each developer answers those questions privately, you get drift. If the answers are generated from the same source, you get consistency.

Project structure: one command instead of tribal knowledge

A scaffolder turns project structure into a repeatable output. Instead of your senior engineer remembering the canonical layout and everyone else approximating it, the layout comes from a template that is identical for every repo.

ScaffoldKit generates production-ready project directories for Python (FastAPI), Node.js (Express), and Go. Every scaffold ships with the boring infrastructure already configured: a multi-stage Dockerfile and docker-compose.yml with frontend, backend, and database services; GitHub Actions CI/CD that lints, tests, builds, and deploys on every push; testing frameworks (Jest + Supertest for Node, pytest for Python, Go testing setup); linting presets (ESLint, Prettier, ruff, golangci-lint); environment file templates (.env.example, .env.development, .env.production); a Makefile with the common commands; and .editorconfig, .gitignore, and a README template.

The result is that “what is the project structure?” has a single canonical answer:

npm install -g @ezralabs/scaffoldkit
scaffoldkit init my-project --stack=fastapi
cd my-project
make dev

Every repo starts from the same template. Code review stops being about layout arguments and starts being about the actual code.

Environment: the machine-level setup nobody documents

The second half of drift lives in the shell. Bashrc files, zshrc files, aliases, prompts, Git shortcuts, Docker cleanup scripts — the stuff every developer configures by hand on a new machine and then never talks about. It is exactly the part that does not show up in the repo, so it is exactly the part that drifts.

DevKit is a developer environment starter pack that removes that whole category: terminal dotfiles with aliases and prompt customization, Git aliases like git-cleanup and git-sync, Docker helpers like docker-cleanup and docker-prune, and project init scripts for common stacks. Install it once and every machine feels like home — including the new hire’s laptop on day one.

The team workflow: install once, scaffold forever

This is where the two tools compound. The reproducible-environment workflow for a small team is:

  1. Every developer installs DevKit once.
  2. Every new repo is created with scaffoldkit init instead of a blank directory.
  3. The answers to “what is the project structure?” and “what is my environment?” are now the same for everyone, by construction.

No platform team. No internal tooling project. No wiki page that is already out of date. Onboarding a new developer becomes installing two tools instead of reconstructing your senior engineer’s laptop from memory.

That workflow is exactly what the ScaffoldKit + DevKit Bundle packages: ScaffoldKit ($39 alone) and DevKit ($9 alone) together for $45 — a $3 saving over buying them separately, one checkout, one-time payment, free updates, on Linux, macOS, and Windows (WSL).

The math matters less than the mechanism. A reproducible environment is not a perk for teams with a platform budget — it is a one-time setup that removes the most expensive sentence in your codebase. If you have ever spent a team afternoon on “works on my machine”, the fix is to stop letting machines be individuals.

More from the Ezra Labs shop: ScaffoldKit, the scaffolder behind reproducible projects; DevKit, the environment starter pack that keeps machines consistent. Explore everything at the Ezra Labs shop.

Similar Posts