Developer tools

What sits in this category

The machinery around writing and shipping code: editors, version hosting, code review, continuous integration, package registries, environment tooling and release management.

Products here are bought by the people who use them, which makes the category unusually honest. Developers abandon tools that waste their time, and no procurement process keeps a bad one alive for long.

Watching software in production belongs in monitoring. Interface work for APIs sits in API and integrations. Model-assisted coding is in AI tools.

The pipeline is the product

Most of what a team feels day to day comes from the path a change takes between a laptop and production.

That path has four checkpoints: review, automated tests, a build artifact and a deployment. Every product in this category improves one of them or connects two.

Speed is the metric that changes behaviour. A pipeline finishing in four minutes gets used constantly. One taking forty minutes changes how often people push, encourages larger changes, and makes review worse. When comparing continuous integration services, measure a real build of your own repository rather than reading a benchmark.

Reliability matters as much. A test suite that fails randomly teaches everyone to rerun rather than investigate, and once that habit exists the suite has stopped protecting anything.

Version hosting and review

The hosting platform decides more than where code lives. It sets how review works, what runs automatically, who can approve, and what history looks like a year later.

Check protected branches, required checks, review assignment and whether approvals can be enforced rather than suggested. Then check the ordinary ergonomics: how a large change renders, whether comments survive a rebase, and how easy it is to find why a line was written the way it was.

Migration between platforms is possible and never free. Code moves cleanly, and issues, pull request history and automation usually arrive in a worse state than they left.

What to look at in the rest of the toolchain

• Package registries, private for internal libraries and cached for public ones so an outage elsewhere does not stop your build.
• Environments, reproducible on a laptop and in the pipeline without a page of setup instructions.
• Secrets, injected at build time and never committed, with rotation possible without downtime.
• Artifacts, versioned and retained long enough to roll back to last week rather than yesterday.
• Release tooling, whether that means feature flags, staged rollouts or a plain tagged deploy.

Feature flags deserve a note. They make releases calmer and become technical debt if nobody removes them, so ask how the tool handles retirement rather than creation.

Pricing that reflects usage, not headcount

Continuous integration is billed by minutes, by concurrency or by contributor. Faster machines cost more per minute and often less per build, which is why the useful comparison is cost per successful build at your repository size.

Storage for artifacts, caches and container images accumulates silently, and retention defaults are usually generous to the vendor. Seat-based platforms charge for anyone with write access, so dormant accounts are worth reviewing quarterly.

Free tiers here are unusually good, particularly for open work, and unusually easy to outgrow in one busy month. The wider set of quiet meters appears in what pricing pages hide.

What to test before committing

Move one real repository, with its tests and its slowest build, and run a full week of normal work through it.

Then break something deliberately: a failing test, a rejected deployment, a rollback. How a tool behaves on a bad day is the part you are actually buying, and it never appears in the demonstration.

Buying order for a growing team

A team of two needs version hosting with review and a pipeline that runs tests. Everything else can wait, and adding it early costs attention that would be better spent on the product.

At five to ten people, the pressure moves to build times, environment consistency and a private registry for shared code. Those are the points where friction starts multiplying across the team rather than affecting one person.

Beyond that, the questions become release management: flags, staged rollouts, artifact retention and being able to answer what exactly is running in production right now.

Resist buying for the team you expect to have. Tooling adopted before it is needed becomes a configuration nobody remembers making, and removing it later is harder than adding it would have been.