Service · 04 — Custom developer tooling

The small sharp tool your team has been hand-rolling.

Every team has the script that lives in someone’s home directory, the JIRA macro nobody else can read, the cron job that broke in 2023. The studio builds the proper version — small, documented, in your repo, with tests where they matter.

What you get

• A real tool with a real interface — proper argparse / commander, helpful --help, sensible defaults, exit codes that mean something.
• Tested where it matters — input parsing, edge cases, the “works on my machine” surface. Not 100 % coverage theatre.
• A README that’s honest about the rough edges — what it does, what it doesn’t, what surprised us building it.
• CI on day one — GitHub Actions wired so “does this still work” never has to be answered manually again.
• Distribution that fits your team — pip, npm, a homebrew tap, a single binary, or just “clone and go”. We’ll pick what your team will actually use.
• Source in your repo, not on a laptop. Your code, your fork, your future.

Examples of what fits

• Internal CLIs that wrap a tedious workflow into a single command (deploy, rotate secrets, scaffold a new service).
• Data pipelines that move a CSV / API / SaaS export into the place it actually needs to be, on a schedule.
• Migration scripts you only run once but absolutely must run correctly the first time.
• Custom GitHub Actions for your team’s workflow patterns.
• Code-mod scripts — find & rename across a thousand files, with a dry-run mode and a real diff before you commit.
• Linting / pre-commit rules specific to your codebase’s conventions.

How scope-first works

1. One paragraph: what does the tool do? What input, what output, what gets easier.
2. We reply with the smallest version of that — what we cut, what we keep, what an honest week-or-two of work looks like.
3. Fixed-scope quote. If we discover the “real” problem mid-build, we stop, re-scope, agree on a delta — never silent scope creep.
4. Ship, hand off, leave a README. The next engineer (or your future self) doesn’t need us to extend it.

Honest answers

Will it be over-engineered?

No. Gold-plating is how small tools die. If you ask for a Bash script and a Bash script fits, you get a Bash script with a header comment and a set -euo pipefail, not a Kubernetes-deployed microservice.

What about ongoing support?

Optional retainer for security updates, dependency bumps, and small extensions. Most of these tools don’t need it — that’s the point of small & sharp.

Cost?

Smallest scopes (a focused script, ~1 week) start in the high three figures. Multi-command CLIs with packaging, distribution, and tests scale from there. Quote within two business days.

Open source?

If the tool is generic and would help others, we’ll suggest open-sourcing it (on your terms — your repo, your license, your name). If it’s yours alone, it stays yours alone.

Stack

Py / TS / Bash

Turnaround

1–4 wks

Format

Fixed scope

Location

Remote, US