How much does a custom internal tool cost?

Two quotes and a spreadsheet

An operations lead we know needed a tool for tracking equipment loans: who has what, when it’s due back, an approval step for the expensive items, an export for finance. Nothing exotic. She collected two quotes.

The agency quoted $68,000 and fourteen weeks. The low-code vendor quoted $35 per user per month, which sounded like a rounding error until she multiplied it by forty users and sixty months and got $84,000, paid on the installment plan.

So the equipment tracker stayed where it had always lived: in a spreadsheet with a tab named “DO NOT SORT.”

That spreadsheet is the real competitor for every internal tool, and it persists because the honest answer to “how much does a custom internal tool cost?” has been, for a long time: more than the problem feels worth. Here is where that money actually goes, and what has changed.

The traditional answer: $30,000 to $150,000, then rent

Ask a development agency to build an internal tool (a dashboard, an approvals workflow, a small CRUD app over a database) and quotes cluster between $30,000 and $150,000 depending on screens, integrations, and how many meetings it takes to agree on what “done” means. In-house isn’t cheaper; it just hides the invoice. Two engineers for six weeks is a $40,000 tool before anyone reviews the pull request, and those engineers were supposed to be building the product.

The build price is also only the entry fee. The industry’s rule of thumb for maintenance is 15–20% of build cost per year: dependency updates, the SSO migration, the field that legal suddenly needs, the person who wrote it leaving. A $70,000 tool is a $200,000 tool over five years. Estimates rarely say this out loud, because the number kills the project, and the spreadsheet wins again.

The low-code answer: cheap to start, priced like a hostage later

Low-code platforms saw all of this and made a fair offer: skip the engineers, drag and drop, pay per seat. For year one it’s the cheapest option on the table.

The economics turn in year two. Per-seat pricing scales with adoption, so the more useful the tool becomes, the more it costs, which is the opposite of how software economics should work. And when you hit the platform’s ceiling and want out, you discover the exit price: your “app” is configuration on a vendor runtime, and leaving means a rewrite. We’ve written about why that trade-off is collapsing; the short version is that the trade was only ever justified by real code being too expensive to produce.

The question is actually three questions

Every estimate that burned someone priced only the first of three costs:

1. Build: getting from a description to a working tool.
2. Run: hosting, backups, security patches, keeping the lights on.
3. Change: the field, the report, the new approval rule, forever.

Traditional development front-loads everything into build and bills change at consulting rates. Low-code hides build inside run and makes change free right up to the ceiling, where it becomes impossible. Any honest cost comparison has to price all three.

What the same tool costs on Sapilon

Sapilon prices the three costs separately, and publishes each one.

Build is AI work, billed in points: a fixed, published unit (1 point = $0.156) instead of token math. A focused change to one component runs 10–25 points; a full page, back end and front end, runs 40–120. Our operations lead’s equipment tracker is five or six screens plus an approval flow and an export: on the order of 500–1,500 points of AI work, or roughly $80–$250. Not per month. Total, for the build.

That number looks like a typo next to $68,000, so let’s be precise about what it does and doesn’t include. It covers the AI building the tool: schema, pages, workflow, tests. It does not include your own time describing what you want and checking the result, and it does not include the places where you should want a human.

Run is hosting in your own AWS account, billed as flat tiers with round numbers, kept deliberately near cost because infrastructure markup is not where we make money. An internal tool for forty people sits comfortably in the smallest tiers. The app moves through Build, Rehearsal, and Live Server environments like any real deployment, because it is one.

Change is the same as build: points. The new field legal wants is a focused change, a handful of points, minutes later. There’s no statement-of-work, no ticket aging in a backlog, and no ceiling. Under the platform there’s an ordinary codebase in plain Git, so anything is buildable and any engineer can step in.

And sometimes judgment matters more than speed: is this data model right, is this integration safe, should finance sign off on how the export rounds? Then you can pull in a vetted human expert at a published all-inclusive price sized to the job. A tool that touches money might spend a few hundred dollars on expert review. That’s not a hidden cost; it’s the part of the old $68,000 that was ever worth paying for.

The line item nobody prices: leaving

One more number belongs in the comparison, because it dominates the others in bad scenarios: what it costs to stop.

Stop paying an agency and you keep the code but lose the only people who understand it. Stop paying a low-code vendor and you keep a login page. Stop paying Sapilon and you keep the software: a normal repository, open libraries, running in your own cloud account. The exit costs nothing because there is nothing to exit. We think that should be table stakes for anything you run your operations on, and it’s why “how fast can it build?” is the wrong first question to ask any AI tool.

So, the answer

For a typical internal tool (a handful of screens, a workflow, some reporting):

The equipment tracker got built, for less than the agency charged for its estimate. The spreadsheet is still around; someone kept it “just in case,” which after fifteen years of DO NOT SORT is fair enough. But nothing new has been added to it since March, and in internal-tools terms, that’s what victory looks like.