The Year of Internal Tools
Geocodio explains how AI models enable their small team to build and maintain full-fledged internal applications rather than simple scripts, completely changing their workflow.
summary is enough Skim this practical case study on AI-driven internal app development, though the debates around long-term maintenance costs are familiar.
summary
Geocodio recounts how AI tooling transformed their internal software development, allowing them to build comprehensive apps like custom support platforms and sprint planners rather than isolated scripts. By leveraging rigorous up-front planning, automated documentation rules, and shared component libraries, they offset traditional maintenance hurdles. However, they maintain strict boundaries against in-housing core SaaS products like email or communications infrastructure. The approach highlights how AI shifts the economic balance of building custom enterprise workflows.
key points
- AI significantly lowers the cost of both building internal applications and handling their long-term maintenance burden.
- Rigorous up-front planning, strict documentation maintenance rules via CLAUDE.md, and shared UI component libraries prevent sprawl.
- The team draws a hard line against replacing core third-party infrastructure like email or billing, focusing only on tools that deeply integrate internal data.
who should read it
Engineering leaders and developers evaluating how AI changes the ROI of building custom internal tooling.
discussion skeptical
consensus
Commenters are skeptical, noting that lower building costs do not eliminate the long-term maintenance burden or the risk of building tools that teams ultimately abandon.
pushback
A minority view suggests that vibe-coded apps can become disposable, provided the foundational platform handles critical safety guarantees like auth and backups.
Going through this learning process is a critical growth point in every software development career:
1. Software developer is required to do some mundane configuration/setup/data manipulation task at the request of some other internal team
2. Software developer thinks "I'll write an internal tool so the internal team doesn't have to bug me! They can change the configuration/extract the data on their own!"
3. Software developer spends X amount of time building an internal tool (can be quite quickly with AI)
4. Internal tool is released; the internal team looks at it and says, "uh, I don't …
It highlights the classic pitfall where developers build internal tools that internal teams ultimately reject or refuse to use.
Generated by an LLM from the article and thread. Check the sources before relying on it.