Why two honest quotes differ by ten times
You described the tool in a paragraph. One firm came back at $40,000 and eight weeks. Another came back at $400,000 and nine months. The instinct is to assume one of them is padding, and sometimes one is. More often they read the same paragraph and made different assumptions about the parts you did not write down: how many people use it, whether it has to talk to anything else, who has to approve it before it goes live, what happens to the data that already exists, and who is on the hook when it breaks on a Sunday. Those five things move the price far more than the features you listed.
The spread is not evidence of dishonesty. It is evidence that the request was underspecified, which is normal, because you are not supposed to know how to specify software. But it does mean that comparing the two numbers is meaningless until you make the assumptions visible. A buyer who does that gets bids that differ by thirty percent instead of a factor of ten, and thirty percent is a decision you can actually make.
What follows is what we would tell a friend running an operations team who has been asked to get a number by Friday. It is written from the seller's side of the table, which means some of it is not flattering to sellers.
What you are actually buying is hours
Custom software has almost no material cost. Nearly everything you pay for is a person thinking, and the price of the tool is the number of hours multiplied by a rate. That is why "can you make it cheaper" is usually the wrong question and "can we do less of it" is usually the right one.
Rates in the United States market cluster in recognizable bands. A solo contractor or a small shop of two or three people runs roughly $110 to $180 an hour. An established firm with senior engineers, a project manager and someone accountable for the outcome runs roughly $175 to $275. Large consultancies and systems integrators run $250 to $450, and a meaningful share of those hours will be delivered by people two years out of school. Offshore teams quote $35 to $90, and the honest version of that trade is that you are converting money into your own management time, plus a time zone gap on every question.
Multiply those out against a real project. A tool that takes 600 hours costs about $90,000 at $150 an hour and about $210,000 at $350. Same tool. The rate is not the interesting variable; the hour count is, and the hour count is set by scope decisions you control.
Four tiers, and where most requests actually land
Almost every internal tool request we see falls into one of four tiers. The bands below are for a competent United States firm at mid-market rates, for a tool built from scratch on ordinary web technology, with the assumptions stated in the last column. Treat them as a sanity check on a quote you already have, not as a price list.
| Tier | What it is | Build cost | Duration and assumptions |
|---|---|---|---|
| A form and a table | One workflow, one or two roles, data entered by hand, exports to a spreadsheet | $15K–$45K | 3–7 weeks. No integrations, no migration of old data, no security review beyond your normal one |
| A real internal app | Four to eight screens, two or three roles, one system it talks to, reporting people actually use | $60K–$180K | 2–5 months. One integration with a documented API, a modest amount of historical data to bring across |
| A system the business runs on | Replaces the spreadsheet or old app that operations depends on. Audit trail, permissions, several integrations, real migration | $180K–$500K | 5–10 months. Multiple integrations, a regulated or audited process, data that has to be reconciled before cutover |
| A platform | Several business units or external users, single sign-on, a compliance regime, an availability commitment | $450K–$1.5M+ | 9–18 months. Security review by a third party, uptime obligations, an operations plan that exists before launch |
The tier boundary that surprises people most is between the second and the third. Adding an audit trail and a permissions model to an otherwise simple app is not a feature, it is a change in what the software has to guarantee, and it touches every screen and every database write. If your tool will ever need to answer "who changed this field, when, and what was it before," say so in the first conversation. It is far cheaper to design in than to add.
You are probably here because
- You have two quotes that differ by more than you can explain to a CFO
- Somebody asked what a number should be and you have no anchor at all
- The tool you paid for two years ago now costs more to keep alive than it did to build
- You are trying to decide whether to buy a product, build one, or keep the spreadsheet
The tiers above give you the anchor. The next two sections explain why quotes diverge and what the number leaves out.
The five things that move the number
How many other systems it has to talk to. This is the biggest single driver and the one most often left out of a request. Each integration carries an authentication scheme, a data model that does not match yours, rate limits, a sandbox that may not exist, and a vendor who may charge for API access. Budget $8,000 to $40,000 per integration depending on how well documented the far side is, and add a large multiplier for anything on-premises with no API at all.
Whether old data has to come across. "Start fresh" and "bring over the last seven years" are different projects. Migration cost is driven by how dirty the data is, not how much of it there is. Ten thousand records with inconsistent customer names and free-text dates cost more than ten million clean rows.
Who has to approve it. A tool used by twelve people in one department passes through your normal review. A tool touching customer records, payment data or health information passes through legal, security and possibly an external assessor, and that review consumes weeks of calendar time and real engineering hours answering questionnaires. If a security questionnaire is in your future, it belongs in the quote.
Whether it replaces something people already use. Replacing is harder than introducing. You inherit every undocumented behavior of the old thing, plus the political work of taking away a tool somebody built and is proud of. First-time tools are the cheapest software you will ever buy.
What happens when it breaks. A tool that can be down for a day while somebody looks at it on Monday is a different engineering problem from one that gates the loading dock. Availability is bought with redundancy, monitoring, alerting and a person on call, and each of those is a line item.
What drives the price of an internal tool
Our own weighting when we estimate this class of work. Judgment from practice, not a measured statistic.
Notice the bottom row. Buyers spend a surprising amount of negotiating energy on which framework or cloud the vendor proposes. For an internal tool with a few hundred users, that choice affects cost less than almost anything else on the list. Spend the energy on the top two rows instead.
The costs a build quote does not include
A build quote covers building. It usually does not cover the four things below, and all four arrive whether or not anyone budgeted for them.
Running it. Hosting an internal tool for a few hundred users is genuinely cheap now: a small managed database, an application host and file storage commonly total $80 to $600 a month. What is not cheap is anything that processes documents or images at volume, anything with a large analytics workload, and anything calling a commercial AI model on every request. If your tool has an AI feature, ask for the per-transaction cost at your expected volume and the number at ten times that volume, and get both in writing.
Keeping it alive. Dependencies get security patches, browsers change, the vendor on the other side of your integration ships a breaking API version, and somebody's certificate expires. A useful planning figure is fifteen to twenty-five percent of the original build cost per year, every year, just to hold position. A $150,000 tool is roughly a $25,000 to $37,000 annual commitment before a single new feature.
Changing it. Any tool people actually use generates requests. That is a good sign, not a failure of the requirements. Budget for it deliberately, either as a retainer or as a small annual pool, so the request queue does not become an argument.
Your own people's time. The largest uncosted item on most projects. Somebody in your organization has to answer questions, make decisions, test, and get colleagues to adopt the thing. On a four-month build, that is typically six to ten hours a week from one person who knows the process, and it is not optional. Projects where nobody was given that time are the ones that finish late and land badly.
Buy, build, or keep the spreadsheet
The honest default is buy. If a product covers eighty percent of the workflow and the parts it misses are annoyances rather than blockers, buying is almost always cheaper over three years, and the parts you dislike are usually cheaper to accept than to build around.
The arithmetic worth doing: take the three-year cost of the product, including per-seat fees at the headcount you expect to reach, implementation, and any connector or premium tier the integration requires. Compare it against the build cost plus three years of maintenance at twenty percent. If the product comes in under sixty percent of the build number, buy it and stop the analysis. Between sixty and a hundred percent, the decision is about fit and switching risk rather than money. Above a hundred percent, building starts to make sense on cost alone.
Two things push toward building even when the money says otherwise. The first is when the process is genuinely how you compete, in which case bending it to a product's shape is a strategic cost you cannot see on the invoice. The second is when every product in the category charges per seat and you expect to triple the seat count. Per-seat pricing that looks cheap at twenty users is a different conversation at three hundred.
And the spreadsheet deserves more respect than it gets. A spreadsheet that four people share and that nobody has broken is a working system. The moment to replace it is when one of these becomes true: two people edit it at once and lose each other's work, someone outside the team needs a filtered view, you cannot answer what it looked like last month, or the person who built the macros is leaving. Until one of those is true, replacing it buys very little.
How to make bids comparable
You do not need a specification to get comparable bids. You need to state the same seven things to everyone, and require that the response follow the same order.
- The workflow in your own words, start to finish, including what happens when it goes wrong
- Who uses it and how many, today and in two years, with their roles named
- Every system it must talk to, and whether you have someone who can get API access to each
- What happens to existing data: start fresh, import a subset, or migrate everything with reconciliation
- Who has to approve it before launch, and whether a security questionnaire is involved
- What downtime costs you, in plain terms, for an hour and for a day
- Who will own it afterward, and whether that is your staff, the vendor, or nobody yet
Then require every bid to break the price into discovery, build, data migration, integrations itemized one by one, testing and acceptance, deployment, training and handover, and the first year of support priced separately. A bid that arrives as one number is not a bid you can evaluate, and asking for the breakdown costs the vendor an hour. If a firm will not itemize, that is information.
Ask what you own and where it lives
Write into the agreement that the source code lives in a repository your company controls from the first commit, not delivered at the end. Add that the deployment runs in your cloud account under your billing, and that you receive the credentials. Neither costs the vendor anything if they intended to behave well, and both remove the failure mode where a working tool becomes unmaintainable because the only copy of it is somewhere you cannot reach. We have been asked to take over more than one system where this was the entire problem.
Where the money gets wasted
- Buying the cheapest bid on a tool the business will depend on, then paying twice to have it rebuilt
- Paying for a discovery phase that produces a document instead of a working slice
- Scoping every feature anyone mentioned, when half of them serve a case that happens twice a year
- Approving a build with no named owner inside the company for the day after launch
- Treating training and adoption as free, then concluding the software failed
- Signing a fixed price against a scope nobody can describe, which becomes a change-order argument by week six
- Letting the vendor hold the code, the cloud account, or the domain
The second item deserves a word, because it is the one buyers most often defend. Discovery is real work and worth paying for. But a discovery phase should end with something running, even if it is one screen against real data, plus a fixed price for the rest. A discovery that ends only with a slide deck and an estimate has transferred no risk and taught you very little that a long conversation would not have.
A shape that keeps the risk small
How we would stage a mid-size internal build
The point of stage two is not to be nice to the vendor. It is that a small group of real users on a real workflow discovers more about your requirements in two weeks than four months of specification will. Every project where we shipped something narrow early ran closer to its estimate than the ones where the first release was everything at once.
Bottom line
Most internal tools worth building land between $60,000 and $500,000, and where in that range depends on integrations, data migration, review obligations and availability, not on features or framework. Add fifteen to twenty-five percent a year to keep it alive and a named person inside the company to own it. Get bids itemized the same way, insist on owning the code and the cloud account from day one, and ship something narrow to real users before the money is mostly spent. Those four habits are worth more than any discount you will negotiate.
Frequently asked questions
On the invoice, yes, often by half or more. In total cost it depends almost entirely on whether you have someone who can write clear requirements and review work daily. Offshore delivery converts money into your management time and adds a time-zone gap to every clarification. It works well for large, well-specified builds with a strong internal technical lead, and poorly for small ambiguous ones where the requirements emerge as you go.
Plan on fifteen to twenty-five percent of the original build cost per year for a system that is holding position: dependency and security updates, breakages caused by other vendors' changes, small fixes and monitoring. New features are separate. If a support agreement is quoted at five percent, ask specifically what it covers and what the hourly rate is for everything else.
Fixed price is right when the scope is genuinely knowable, which usually means after a discovery phase rather than before it. Time and materials is right during discovery and during open-ended work like migrating messy data. The common failure is a fixed price agreed against a paragraph, which turns into a change-order dispute for both sides. Pay for discovery on time and materials, then fix the price for the build.
Look at the itemization rather than the total. Ask how many hours are behind each line and what rate was used. Then ask what assumption each estimate rests on, and what happens to the price if the assumption is wrong. A firm that has thought about the work can answer both immediately. Padding usually shows up as a large undifferentiated line for build with everything else priced thinly, because the risk had nowhere else to go.
Usually not on aesthetics, and usually yes on one of four triggers: the only person who understands it is leaving, it blocks something the business now needs to do, it has become a security or compliance finding, or its running costs are rising faster than its value. If none of those is true, the money is better spent elsewhere and the tool can keep working.