Start by admitting this is not a product decision
An internal tool has no revenue line. Nobody buys it, nobody renews it, nobody writes a review of it. Its entire return is the time it gives back to people who already work for you, and that return is bounded by how many of them there are and how much of their week the task consumes. That single fact should govern the decision, and it usually gets skipped, because build-versus-buy conversations import their instincts from product work where differentiation and lock-in are the deciding variables. For a tool forty people in operations will open twice a day, they are not.
Run the bound first. Take the number of people, the hours per week the task takes them now, the fraction the tool plausibly removes, and a fully loaded hourly cost. Forty people, three hours a week, half of it removed, at $65 an hour fully loaded, is about $200,000 a year of recovered time. That is the ceiling on what the tool is worth, in the best case, assuming the recovered hours go into something useful rather than evaporating. Any option costing a meaningful share of that number has to justify itself against a bound you now know.
Most internal tool requests do not survive that calculation. The ones that do are obvious afterward. It is a ten-minute exercise that decides more than the rest of the process combined, and it gets skipped because it can produce an answer nobody wants: do nothing, the spreadsheet is fine.
You are probably here because
- A vendor quoted a per-seat price and someone internal said “we could build that”
- You have a build estimate and a subscription price and no way to compare them
- The tool you bought last year is used by four of the thirty people it was bought for
- Somebody already built it, they have left, and nobody can change it
The seat-math section below makes the two numbers comparable. The two sections after it list what neither number includes, which is where the comparison usually goes wrong.
There are four options, and the debate usually names two
Framing this as build versus buy hides the two options that most often win. The full set is: keep doing it the current way, configure something you already own, buy a product, or build one. A serious evaluation prices all four, because two of them are nearly free and get eliminated by reflex rather than by evidence.
Keep the current process. The baseline is not zero. It has a real cost, which is exactly the number you computed above, and it also has a real value: it works today, everyone knows it, and it fails in familiar ways. The bar for replacing it is not "a better tool exists." It is "a better tool exists and the switch is worth the disruption."
Configure what you already pay for. Most mid-size companies are running a CRM, a ticketing system, a data warehouse, a business-intelligence tool and an office suite, and at least three of those now ship an assistant, a workflow builder or an extraction feature. It is unglamorous, it is frequently ugly, and it is often 80 percent of the requested value for two weeks of somebody's time and no new contract. Check this before anything else.
Buy a product. Somebody has already built the thing, sells it to a hundred companies, and amortizes the maintenance across all of them. That amortization is the entire argument for buying, and it is a strong one.
Build it. You get exactly what you asked for, you own the data path, and you inherit every future decision about it, forever, including the ones that arrive after the person who built it has moved on.
How often each option is the right answer — internal tools, our experience
Shares sum to 100. Our read across the internal-tool requests we are asked to price, not a survey. The ordering is the useful part, and note that we make less money on the top two.
The seat math, and where it flips
Buying is a cost that grows with headcount. Building is a cost that grows with change. That is the whole comparison, and it is enough to get a defensible answer on one page.
Say a product costs $60 per user per month. Forty users is $28,800 a year, and if the team grows to seventy it becomes $50,400 without anybody signing anything. A build for the same job might be $110,000 once, plus a maintenance tail. That tail is the number people leave out, and for an internal tool with a handful of integrations it runs about 15 to 25 percent of the build cost per year: patches, dependency upgrades, the API on the other end changing, a schema moving, someone needing a new field. Call it $22,000 a year at the midpoint.
| Year | Buy, 40 seats at $60/mo | Build at $110K plus 20% tail | Running difference |
|---|---|---|---|
| Year 1 | $28,800 plus setup | $110,000 | Buy ahead by roughly $81,000 |
| Year 2 | $57,600 cumulative | $132,000 cumulative | Buy ahead by $74,400 |
| Year 3 | $86,400 cumulative | $154,000 cumulative | Buy ahead by $67,600 |
| Year 5 | $144,000 cumulative | $198,000 cumulative | Buy ahead by $54,000 |
| Year 5, at 100 seats | $360,000 cumulative | $198,000 cumulative | Build ahead by $162,000 |
Two things fall out of that table. The first is that at forty seats, buying stays ahead for longer than the five-year window most people use, so a five-year total-cost model is not a tiebreaker, it is a decision. The second is that headcount is the variable that flips it. A tool for a team that will double is a different question from a tool for a team that will not.
Do not skip the second thing that flips it: a per-seat price that assumes everyone needs a seat. Many internal AI tools are used properly by a third of the people they are licensed for. If the honest daily user count is twelve rather than forty, the buy column shrinks by two thirds and the argument stops being close. Measure this before renewing, not after.
What the buy quote does not include
A subscription price is not the cost of buying. Four things sit underneath it, and none of them show up in the vendor's proposal because the vendor does not incur them.
Getting your data in. Every useful internal tool needs to see your systems, and the connector is either a build or a professional-services line item. Budget $15,000 to $60,000 for a real integration into a system with a stable API, more if the system on your side is old or the data needs cleaning first. This is where "we bought it" quietly becomes "we bought it and built something."
Configuration and the first ninety days. Somebody has to set up the fields, the permissions, the workflows and the exceptions, and then sit with the first users while they discover what does not fit. This is a quarter of a person for a quarter, and it is why tools bought in the last week of a budget year so often go unused.
The review that gate-keeps it. If the tool touches customer data, personal data, contracts or anything regulated, there is a security review, a data-processing agreement, and possibly a privacy assessment. Six weeks is normal; three months is not unusual. Start it the week you shortlist, not the week you sign.
The exit. Ask, in writing and before signing, how you get your data out, in what format, and what happens to the model configuration and the accumulated corrections your staff made. A vendor with a clean answer is telling you something real. A vendor who has to check is telling you something too.
Price the pilot as though it were the contract
A free or heavily discounted pilot is a good idea and a bad basis for a decision, because it usually skips the integration, the permissions model and the security review — which is to say, it skips the three lines that make the real number. Run the pilot, and separately price what the full deployment costs with those three included. The gap between the pilot experience and the deployed cost is where most buyer regret comes from.
What the build quote does not include either
The symmetric honesty, from the side that sells building: a build estimate covers getting to a working tool. It does not cover keeping one.
The maintenance tail. Fifteen to twenty-five percent of the build cost per year, and it is not optional. Dependencies get security advisories. The system on the other end of the integration changes its API. A model provider deprecates the version you pinned. Somebody in operations needs one more column. Skip a year of this and you have a tool nobody trusts; skip two and you have one nobody can safely modify.
Whoever answers when it breaks. An internal tool that forty people depend on at 9am has an on-call story, even if the story is "Priya looks at it when someone messages her." Write down whose job it is. If the answer is nobody, the tool will be abandoned rather than fixed, which is the most common ending for internal software and rarely appears in anyone's model.
The running cost of the AI part. Model calls are metered. A tool doing document work at any volume can run a few hundred to a few thousand dollars a month, and the cost scales with usage in ways a subscription does not. Estimate it from a real sample of documents before you commit, and put a hard spend cap in the code on day one.
The second version. Internal tools generate requests the moment they work. That is a sign of success and a budget line. Assume the first twelve months after launch contain a second, smaller project.
Cost lines commonly absent from the quote you are holding
How often we find each line missing when we are asked to review a build quote or a subscription proposal. Judgment from the quotes we read, not a formal sample.
The three questions that actually decide it
Once both columns are honest, the answer usually falls out of three questions. Everything else is detail.
Does the tool encode something specific to how you work? Not "our process is unique" — almost every process believes that. The test is narrower: is there a rule, a taxonomy, a sequence or a judgment in this workflow that a vendor serving a hundred companies would refuse to support because only you need it? If yes, a bought product will be fought with for two years and then replaced. If no, buy.
Does the data have to stay inside a boundary? Some data cannot leave the building, or cannot leave a specific cloud region, or cannot be processed by a subprocessor your customer has not approved. This is a real constraint and it eliminates most of the market quickly, but check whether it is actually true rather than assumed. Many vendors now offer a deployment mode that satisfies it, and "we cannot send this to a vendor" is stated far more often than it is verified.
Will anyone still own this in three years? Build only if you can name the person or the team who will hold it, and only if that name survives the obvious question of what happens when they leave. An internal tool with no owner is a liability with a login page. This question kills more build proposals than cost ever does, and it should.
Send us the two options and we will tell you which one we would pick.
Email the build estimate, the vendor pricing, the seat count and what the tool has to talk to, to contact@precisionfederal.com. You get back a short written note with the two numbers made comparable, the lines we think are missing from each, and which way we would go. One business day. No charge and no meeting, and we will say buy when buying is right.
contact@precisionfederal.comThe cases where building is clearly right
Four situations, and they are narrower than most build proposals assume.
The workflow is genuinely yours. A distributor whose pricing logic is thirty years of accumulated exceptions, a lab whose sample handling comes from an accreditation body, a team whose scheduling constraints are physical rather than preferential. Products exist near that shape and none fit inside it.
The integration is the whole job. If the value is joining four systems you already run and the AI part is thin, you are buying a connector, not a product. Buying a product here means paying a subscription and still writing the connector.
The data cannot go out, verifiably. Not as a preference but as a contractual or regulatory fact you can point at in writing.
The seat count is large and growing. Past roughly a hundred users on a per-seat product the arithmetic stops being close, in a direction that compounds every year.
The cases where buying is clearly right
Most of the rest, and specifically these.
A category exists with five real competitors. Competition disciplines the price, and the roadmap is funded by everyone else's subscription as well as yours. Building into a mature category buys you a permanent obligation to keep pace with people whose full-time job it is.
The compliance surface is the product. Anything whose main difficulty is an audit trail, a certification or a regulator's expectations. Those vendors have already paid for the audits, and repeating that internally is slow and expensive.
You need it this quarter. A bought tool reaches users in weeks. A built one does not, whatever the estimate says.
Nobody internal wants to own it. Take that seriously as an input, not as a problem to solve with a meeting.
The hybrid that quietly wins
The most common good answer is not on either end. Buy the parts that are commodity — storage, authentication, the document viewer, the model itself, the workflow engine — and build the thin layer that encodes what is specific to you. In practice that is a small connector and a small rules layer sitting between two products you already pay for, at perhaps a fifth of a full build, with almost none of the maintenance surface.
It presents badly — no clean story, no vendor logo — and it is usually correct. If you take one habit from this, make it asking which part of the request is actually specific to you, then buying everything else.
A two-week way to decide
Decision Sprint
Step one gets skipped and step one changes answers. Watching the work is how you find out that the painful part is not the one in the request — that the real cost is chasing four people for approvals rather than reading the documents, in which case no AI tool of any origin was going to help.
Where these decisions go wrong
- Comparing a subscription to a build price without the integration line on the buy side or the maintenance line on the build side
- Counting licensed seats rather than daily users, which inflates the buy column by two or three times
- Treating “our process is unique” as evidence instead of naming the specific rule a vendor would refuse to support
- Building because a prototype worked in a week, when the week was the cheap part and the year after it was not
- Buying at the end of a budget cycle with no rollout time booked, then discovering usage never started
- Never pricing “configure what we own”, because it is nobody’s exciting project
- No named owner on the build option, and no plan for what happens when that person leaves
- Ignoring the exit on both sides — vendor data export, and who can modify the built tool a year on
Before you sign either one
- The recovered-time ceiling is computed and written down
- All four options are priced, including doing nothing
- Seat count is honest daily users, with a growth assumption stated
- The buy column includes integration, rollout and review time
- The build column includes a maintenance percentage and a named owner
- Metered model spend is estimated from a real sample, with a cap in place
- The exit path is documented on whichever side you choose
- Someone has watched the actual work being done, this month
Bottom line
Internal tools are bounded by recovered time, so compute that bound first and let it eliminate what it eliminates. Then make both columns honest: buying costs more than the subscription, building costs more than the build. After that the decision is nearly mechanical. Build when the workflow encodes something a vendor would refuse to support, when the data genuinely cannot leave, when the integration is the actual job, or when the seat count is large and rising. Buy otherwise, which is most of the time. And before either, find out whether something you already pay for does 80 percent of it — cheap, unglamorous, and right more often than anyone expects.
Frequently asked questions
Put both on a cumulative timeline at three and five years. Add integration, rollout and review cost to the buy side, and add a maintenance tail of 15 to 25 percent of the build price per year to the build side. Then run the same table at your expected headcount rather than today's. Headcount growth is usually what flips the answer, and the year the lines cross is the number you should be arguing about.
Fifteen to twenty-five percent of the original build cost per year, even with no new features. That covers dependency and security updates, changes forced by the systems it talks to, model version deprecations, and the small requests that arrive because people are using it. Budgeting zero produces a tool that is unsafe to modify within about two years.
When the workflow encodes a rule a vendor serving many customers would decline to support, when the data provably cannot leave a boundary, when the real work is connecting systems you already run, or when the seat count is above roughly a hundred and rising. Outside those four, buying or configuring something you own is usually cheaper over five years and always faster to get in front of people.
Probably not about the weekend, and that is the trap. A working demonstration is genuinely a weekend now. The permissions model, the error states, the integration, the evaluation, the spend cap, the on-call story and the second version are the year that follows. Ask them for the twelve-month plan rather than the prototype, and see whether the enthusiasm survives it.
How the tool reaches our data and who does that work. What the price is at double our current seat count. What the security review requires and how long it has taken other customers. How we export our data and our accumulated configuration if we leave, in what format, and how quickly. A vendor who answers all four cleanly is usually a good partner; one who has to check on the export question has told you something useful.