How much to charge for an internal tool
How much to charge for an internal tool comes down to one question: what is this job costing the team right now? An internal tool replaces a spreadsheet, a shared inbox, a copy-paste routine or a person double-checking someone else's work. Price the build on a share of what that job costs the business over a year, add a line for every system it has to connect to and every kind of user it has to handle, and quote a monthly plan on top. Do not price it on screens or on your hours.
Internal tools are some of the best work you can sell with Claude Code. The users are a known group, the job is already being done badly by hand, and the client can see the result inside a week. The trap is that they look small, an admin panel, a form and a table, so builders price them like a small website. That leaves most of the value on the table.
Why screens and hours are the wrong yardstick
A tool with two screens that ends an afternoon of manual reconciliation every week is worth more than a tool with twelve screens nobody opens. Screens measure your effort, not their outcome. Clients do not care how many pages you built. They care that the Friday report now takes minutes, or that orders stopped going out with the wrong address.
Hours are worse. Claude Code makes the build fast, and if your price follows your hours, every improvement in your speed is a pay cut. I covered this in why I stopped charging hourly for AI builds. The client is buying the job gone, not the time it took you to remove it.
The CCC Team-Week Quote
Four parts of an internal tool quote
| Part | What it prices | Question to ask the client |
|---|---|---|
| Base build | The main job the tool replaces | Who does this job today, how often, and how long does it take? |
| Connections | Each system the tool reads from or writes to | Where does the data live now, and where does the result need to go? |
| Access levels | Each kind of user with different permissions | Who should see everything, and who should only see their own part? |
| Keep plan | Monthly upkeep, fixes and small changes | What happens to this process when the team or the systems change? |
Base build. Work out the yearly cost of the job with the client: the number of people doing it, multiplied by how often, multiplied by how long it takes, multiplied by what that time costs the business. Then price the build at a fraction of one year of that cost. The client should be able to see the tool pay for itself well inside the first year. Add the cost of mistakes if the job is error-prone, such as wrong invoices, missed orders or double bookings, because a tool that stops those is worth more than one that only saves time.
Connections. Every system the tool talks to is a line item: the CRM, the accounting software, a shared spreadsheet, the email service, the database. Each one adds setup, permissions, edge cases and a new way for things to break later. Pricing them separately makes the quote easy to understand and easy to trim. Connect Claude Code to a database gives a sense of what a single connection involves.
Access levels. A tool everyone sees the same way is simpler than one where managers see every record and staff see only their own. Each distinct kind of user means login rules, permission checks and testing as that user. Add authentication with Claude Code covers the build side; on the quote, it is its own line.
Always quote the Keep plan
An internal tool is not finished at launch. The team changes how they work, a connected system updates, someone new needs access, a report needs a new column. If there is no plan for that, the tool slowly drifts out of step with the business and people go back to the spreadsheet. That is the worst outcome for both of you: the client stops getting value, and you lose the account.
Quote a monthly plan as part of the original proposal, not as an afterthought. State what it covers (monitoring, fixes, small changes up to an agreed size) and what it does not (new features, new connections, quoted separately). How to price a maintenance retainer covers the structure, and how to turn a one-off client into a monthly retainer covers the conversation if the client declines at first.
The questions to ask before you quote
- Who does this job today, and how many of them are there?
- How often does the job happen, and roughly how long does each round take?
- What goes wrong when it is done by hand, and what does a mistake cost?
- Where does the information come from, and where does the result go?
- Who needs to see what? Are there people who should not see some of it?
- Who on your side will own the tool after launch, and who reports problems?
Write their answers into the proposal word for word. A quote that says "this replaces the work your team described as taking most of every Monday" sells itself far better than one that lists features. Client discovery questions before you quote has the wider list, and how to scope a Claude Code client project turns the answers into a scope.
How to present the internal tool quote
- Lead with their job, in their numbers. One line on what the job costs today, then the price, so the price reads as smaller than the problem.
- Show the line items. Base build, each connection, each access level, then the Keep plan. Itemized quotes get trimmed, not rejected.
- Gate the payments on proof. A deposit to start, a payment when the team can use the main job on their own data, and the last payment on acceptance. How to structure milestone payments for an AI project covers the schedule.
- Name the owner. Every internal tool needs a person on the client side who owns it. Put that name in the proposal.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
How much should I charge for an internal tool?
Price it on what the job it replaces costs the business each year: the people doing it, how often, how long it takes, and what mistakes cost. Charge a fraction of one year of that cost for the build, add a line for each system it connects to and each kind of user, and quote a monthly plan for upkeep.
Should I charge hourly for an internal tool?
No. Claude Code makes the build fast, so hourly pricing means every gain in speed lowers your pay. Price on the outcome for the team, and keep the hours as your own private measure of whether the project was worth it.
Is an internal tool cheaper than a customer-facing app?
Often it is simpler to build because the users are a known group and the job is already defined. That does not make it cheaper to buy. If it removes a weekly chore for a whole team, its value can be higher than a public app nobody uses yet.
Do I need to charge a monthly fee for an internal tool?
Quote one every time. Teams change how they work and connected systems change too, and a tool without upkeep drifts out of step with the business. Say what the plan covers and what is quoted separately.
How do I lower the price without discounting?
Remove scope, not margin. Take out a connection, merge two access levels into one, or move a secondary feature into a later phase, and show the client which line changed.
Last reviewed by Duncan Rogoff on October 4, 2026
