What you are buying
Developer tools for sale range from hosted APIs and CI integrations to paid CLIs, SDKs, editor extensions, and commercially licensed libraries. Beyond code and customers, a buyer is acquiring trust inside other people's build pipelines: package names that developers install, repositories they star and watch, documentation they bookmark, and API endpoints wired into production systems. Breaking any of those during a transfer can cost customers quickly, because developers notice failed installs and changed endpoints immediately.
Transfer mechanics are specific to each distribution channel. GitHub's documentation says a transferred repository keeps its issues, pull requests, stars, watchers, and webhooks, and that old URLs redirect, but creating a new repository at the old location permanently deletes those redirects and GitHub Pages sites are not redirected. On npm there is no direct transfer: the new owner is added as a maintainer and the old owner removes themselves, and scoped packages cannot be moved to another user or organization at all because the scope belongs to the owning account. Revenue often runs through a usage-based or seat-based plan on Stripe or Polar, so billing continuity follows the same rules as any SaaS business.
What to check before making an offer
Measure real usage, not stars
Ask for API request volume, active API keys, package downloads, and paying accounts over time. Stars and downloads include bots, CI caches, and one-off experiments. Tie revenue to the active integrations that generate it.
Plan every namespace transfer
List the GitHub organization or repositories, package registry names, domains used in docs and API endpoints, and editor marketplace listings. Check whether any packages are scoped to the seller's personal account, since npm says scoped packages cannot be transferred. Agree on redirects and deprecation notices before closing.
Review the open-source and license position
Many developer tools combine an open-source core with paid features. Confirm the license of every component, who holds copyright for outside contributions, and whether a contributor license agreement exists. A permissive core can make it easy for others to fork the free part.
Check security posture and secrets
Developer tools often hold customer credentials, tokens, or source code. Ask about past incidents, how secrets are stored, and who has publish rights to packages. Rotate every publishing token, signing key, and deploy key at closing so the seller cannot ship a release afterward.
Assess support load and documentation
Look at the issue tracker, support inbox, and community channels for response times and recurring problems. Developer customers expect accurate docs and changelogs. Estimate the hours needed to keep up with framework and platform releases the tool depends on.
How these businesses are valued
Developer tools are often valued like SaaS when revenue is recurring and seat- or usage-based, and more like owner-operated products when the founder is the main maintainer and support channel. Usage-based revenue deserves extra attention: it can grow without new customers when existing customers scale, but it can also fall quickly if one large account changes architecture. Ask for revenue by customer to measure concentration before applying any income-based view.
A large open-source following can support a higher price only if it converts to paid accounts. Treat free adoption as an option on future revenue, not as current value, and price the maintenance burden of supporting free users alongside paying ones. Deduct the cost of any rework needed to move scoped packages, change endpoints, or reissue signing keys. RevenueBug shows verified revenue but does not appraise listings.
Model a range with the SaaS valuation calculator, then work through the buyer due diligence checklist.