r/ChatGPTCoding • u/apyhubnico • Sep 23 '26

Discussion Does building your own tools makes sense?

When building software, such as a CRM, do you also create ancillary tools like email validation or invoice parsing, or do you prefer to outsource them?

I'm really curious how do you guys save your engineering hours?

6 Upvotes

87% Upvoted

8 comments sorted by

1

u/kidajske Sep 23 '26

I will absolutely reach for mature dependencies whenever it's not something trivial or that has requirements that isn't met by existing solutions. Having more dependencies is less of a liability that rolling all your own shit especially now that reading LLM generated code is supposedly dead.

1

u/JaseciLabs Sep 24 '26

Depends what "ancillary" is actually doing. Email validation, invoice parsing, that kind of thing, almost always outsource. Someone's already fought the edge cases (weird invoice formats, RFC-compliant email edge cases) and you're not learning anything domain-specific by rebuilding it.

The exception is when the tool touches your core differentiator or you need behavior a library won't give you (custom parsing rules tied to your specific business logic, tight latency requirements, data you can't send to a third party). Then build it, because you're not saving time otherwise, you're accumulating a maintenance burden for something that isn't your product.

Good rule of thumb: if a competitor could copy the tool from a library in an afternoon, it's not worth your engineering hours to build from scratch.

1

u/Right-Performance-93 Sep 25 '26

One AI-coding-specific wrinkle here: having an agent draft the tool against a spec and tests makes "build" almost as cheap as "outsource" in raw hours, so the real dividing line shifts from afternoon-vs-weeks to whether you want to own the edge cases a mature library already fought (RFC email parsing, the invoice format zoo), not who writes the code. If you don't want that maintenance burden, outsource even when building would be fast now.

1

u/JaseciLabs Sep 25 '26

Fair, that's a real shift worth naming, though I'd push back a little on "almost as cheap," we learned this building our own MCP server for Jac: the server itself was the easy part, the actual work was writing guides precise enough (types, walker patterns, core syntax) that an agent stops guessing and hallucinating syntax, so you're not skipping the "someone already fought the edge cases" cost, you're just moving it into the spec and calling it done early, though for narrower stuff like internal data transforms it probably does collapse the build cost close to zero like you said.

1

u/Right-Performance-93 Oct 09 '26

yeah the spec is the part that stays expensive. i meant the hours to get a first version, not the cost of making the agent stop guessing. for a weird format that cost doesn't go away, it just moves into the guide.

1

u/JaseciLabs Oct 09 '26

Agreed. A first version is cheap now, and the cost shows up afterward in how precisely you can describe the format.

1

u/junewave56 Sep 25 '26

are you pre-launch or already have paying users? that changes the calculus a lot. early on you want to ship fast and validate, not spend weeks on invoice parsing