Building a devtools business

Top-down sales (call the CTO, get a meeting, run a pilot) works for big enterprise infra. For everything else, the path is bottom-up: a developer tries it on a Saturday, ships it to a side project, brings it into work, expenses it on a personal card, and finally gets it approved as a line item.

Bottom-up only works if three things are true:

1. Free tier that's actually useful — not a 14-day trial, not a 100-call cap. Something a developer can ship to production for free.
2. Sign-up to first useful response in under 5 minutes — every additional minute halves activation.
3. Documentation that respects the reader — code samples that copy-paste-and-work, error messages that explain what went wrong, search that returns the answer.

Counter-intuition: a free tier that's too generous can prevent paid conversion. Tune so the free tier is excellent for hobby use but constrains team use (rate limits, seat caps, missing observability) so growth into the paid tier feels natural, not extractive.

Developers don't read marketing pages. They read docs. Your docs are your marketing.

What good devtools docs do:

• Quickstart in 5 minutes max — runnable code, real values, expected output
• A 'why' page alongside the 'how' — engineers buy when they understand the design choice, not when you list features
• API reference that's complete — every endpoint, every option, every error code
• Recipes and patterns — common combinations, not just primitives
• Changelog visible — developers trust products that ship and document it

What good DX does beyond docs:

• A CLI that bootstraps a working project in one command
• A local dev environment that mirrors production
• An SDK in the languages your customers actually use (start with TypeScript + Python; add others by demand)
• An emulator or sandbox so developers can run integration tests without real credentials
• Status page that's actually accurate and a public incident history

The cheapest growth investment for devtools isn't ads — it's the next 4 hours of polish on the docs site.

Most successful devtools converge on a three-tier pricing model:

1. Free — hobby use, side projects, learning. Generous but limited by resource caps.
2. Pro / Team — small teams, paid by seat. Adds collaboration features, higher caps, support SLA.
3. Enterprise — usage-based or custom-quoted. Adds SSO, audit logs, dedicated support, custom contracts.

Usage-based pricing aligns incentives but creates one big risk: a customer who reads about your $50k bill on Hacker News. Always:

• Show projected costs in the dashboard (live, not at end of month)
• Send proactive alerts at 50%, 80%, 100% of expected spend
• Cap monthly bills at the dashboard-shown projection without explicit increase
• Make it trivial to downgrade or pause

Common mistakes:

• Free tier too narrow — kills bottom-up motion before it starts
• Seat-based pricing on a single-player tool — Developer #2 in a team won't bother getting a seat
• No usage cap — one viral spike and the customer churns
• Hiding the pricing page — engineers leave. Always publish prices.