An internal tool begins with a problem someone wants to solve. Its obligations continue through updates, support requests, access changes, and the day its original builder is unavailable. I want those obligations in the decision from the beginning. A useful cost estimate gives the firm a view of what it will take to operate the tool, change it, and eventually replace or retire it.
Source
The cost estimate has to include review capacity
GitHub’s 2026 security architecture illustrates that agent-enabled delivery includes controls around writes and execution. Those controls require design and operation alongside implementation.
I would include review, verification, and incident handling in the internal-tool estimate. The proposal is to price the capability the firm can safely operate, using ranges for the work that remains uncertain.
Estimate the life of the tool
Choose a comparison period and define the scope. Include requirements, implementation, integration, testing, deployment, and the effort needed to put users into the workflow. Then add the recurring work: support, access administration, dependency updates, monitoring, and changes to connected systems.
Keep direct spending separate from internal effort. Both matter, but combining them too early can hide the assumptions. An hour estimate needs a stated rate if it becomes a monetary cost, and that rate should come from the firm’s own planning method.
The GDS lifecycle-cost worksheet is a historical reference for cost categories. It is useful for remembering operation, change, and exit; it is not a source of current prices.
Count the work that appears later
An internal tool may depend on an API, a hosting account, a scheduled job, and a credential. Each creates a future task. Providers change behavior. Certificates or secrets need managed rotation. A business owner asks for a new field. Someone must investigate a failed run.
NIST’s Secure Software Development Framework supplies a foundation for maintaining software responsibly. Apply it in proportion to the tool’s exposure and consequence, while keeping the actual work in the estimate.
Include the cost of testing changes and correcting bad results. A tool that writes to another system needs a way to detect and reconcile partial completion. Its support burden can depend as much on those exceptions as on ordinary usage.
Test the ownership assumption
A useful handover asks a second person to deploy or operate the tool using the documentation, locate the configuration, understand a failure, and restore service. Record where they need the original builder.
Check that accounts, source, build instructions, and dependency information remain available through appropriate organizational ownership. The aim is continuity, without putting credentials into documentation or widening access unnecessarily.
If only one person can maintain the tool, reflect that constraint in the comparison. Possible responses include reducing scope, improving documentation, securing support, or selecting a different delivery model.
Proposal
Use scenarios instead of false precision
Build a low, expected, and high estimate for uncertain work. Describe what changes between them: integration instability, a higher support volume, broader use, or a more demanding access model.
For an illustrative annual view, total cost is initial delivery plus the year’s recurring service costs and operating effort, with a separate allowance for expected changes. If comparing multiple years, avoid counting the initial build again each year. Keep a visible provision for retirement or migration.
Compare alternatives over the same period and capability. A purchased product may require configuration and integration; an internal tool may require capabilities the vendor already supplies.
A good estimate does not need to predict every future event. It should make the operating commitment visible enough that the firm can decide whether the capability is worth owning.
Proposal
What I would test next
I would ask a second person to operate and modify the prototype before treating the build estimate as complete. Their experience should update the maintenance and handover assumptions, including whether the team can support the chosen dependencies.