"It's just a weekend project"
When an engineer says "I can build a better version of this SaaS tool in a weekend," they are almost always wrong — not about their ability to write the code, but about what "building the tool" actually means.
They are calculating the Day 1 Cost (writing the initial code). They are ignoring the Total Cost of Ownership (TCO) — everything that comes after.
Think of it like buying a house. The purchase price is visible. The property taxes, maintenance, repairs, insurance, and eventual renovation costs are the iceberg below the waterline. Internal tools work the same way.
The TCO of Internal Tools:
- Maintenance: APIs change. Libraries get deprecated. Security vulnerabilities are discovered. Cloud providers update their SDKs. Someone has to track all of this and apply updates — forever.
- Feature Creep: Internal users will ask for new features continuously. "Can you add a UI?" "Can you add audit logging?" "Can you integrate with our SSO?" You now have an unplanned product roadmap consuming engineering cycles indefinitely.
- Operational Burden: Who is on-call when the tool breaks at 3 AM? Who writes the runbooks? Who handles the incident when it takes down a critical workflow?
- Attrition Risk: The one engineer who wrote the tool leaves the company. Now you have "Zombie Code" — software that runs critical infrastructure but that nobody fully understands. Modifying it is dangerous. Replacing it is expensive.
- Documentation Debt: SaaS tools come with documentation, tutorials, and community support. Internal tools come with a Confluence page that was last updated 18 months ago.
Rule of Thumb: Unless the tool is your core business, Buy is usually the safer economic choice, even if the SaaS subscription looks expensive on a spreadsheet. Three engineers maintaining a custom tool costs approximately $600,000/year in fully-loaded salary. That buys a lot of SaaS subscriptions — and the SaaS vendor's team is 50 engineers focused exclusively on that product.