Should you build your own developer tools? Build vs. use vs. generate

Every developer knows the itch: you hit a tool that is almost right, or you are pretty sure you could build a better one in an afternoon. Sometimes that instinct is correct. More often it is the start of a maintenance commitment you did not mean to sign. The useful reframe is that there are three options now, not two: use an existing tool, build your own, or have AI generate one. Here is how to choose.

The short answer

For a solved, generic problem — formatting JSON, hashing a string, converting CSV — use an existing, well-maintained tool and inherit its years of edge-case handling. Build when the tool encodes something specific to you, when nothing fits, or when a hard constraint forces it. Use AI to generate the small, one-off glue you will read and own — not the load-bearing core you cannot yet evaluate.

Three options, not two

• Use. Someone already solved this well. You pay in a dependency or a bookmark and get correctness and zero maintenance.
• Build. You own the code, the edge cases, the security patches, and the differentiation. Right when the tool is the value, or nothing else fits.
• Generate. AI writes a first draft in minutes. Great for throwaway scripts and glue; risky for anything load-bearing until you have reviewed and tested it like any other code.

The decision framework

Weigh the option against what you actually care about for this tool:

The hidden cost of building

The afternoon it takes to build the happy path is not the cost. The cost is the total cost of ownership that follows it: the second-order stuff that never fits in the original estimate.

This is how a "quick internal tool" becomes technical debt with your name on the commit.

What you should almost never build yourself

Some categories are correctness- and security-critical, dense with edge cases, and already solved by native platform APIs. Rolling your own is a well-known footgun:

• Cryptography. Hashing, secure random, token verification. Use the Web Crypto API — or a hash generator and UUID generator that already do.
• Format parsers. JSON, CSV, dates. Native JSON.parse and a mature CSV parser handle quoting, escaping and encoding you will otherwise get wrong — reach for a JSON formatter or CSV converter instead.
• Regex engines and sanitizers. Use the built-in engine and test against it with a regex tester; never hand-roll HTML sanitization.

When building is the right call

• The tool is the product. If it is your differentiator, own it.
• Nothing fits. Your bespoke internal format or workflow has no off-the-shelf match.
• Constraints forbid SaaS. Air-gapped, regulated, or privacy-sensitive environments where sending data out is not an option.
• Learning is the goal. Building a parser to understand parsers is time well spent — just do not ship it as infrastructure.

If you do build, build local-first

When building genuinely wins, the modern browser hands you most of a tool for free — the Web platform APIs cover parsing, crypto, canvas, and files without a server. Building local-first means no backend to secure, no data leaving the user's device, and a tool that keeps working offline. If you lean on AI to scaffold it, generate the boilerplate but own the review — the same discipline as vibe coding safely, and mind the data-handling of whatever assistant you use per the AI coding tool privacy guide.

The honest take

We build local, offline-first developer tools for a living, so treat this as informed rather than neutral: the point is not "always build" or "never build." It is that for solved, deterministic problems, a tool you did not have to build — and do not have to maintain, patch, or document — is usually the best return on your time. Save your building for the problems that are actually yours. For the flip side of this decision — when to reach for a tool versus an AI at all — see AI vs automation for developer tasks, and for why local-first is the right default when you do build, see why offline-first developer tools matter.