Perspective

One-time money buys recurring obligations

Grant funding, emergency relief and one-off capital buy technology that costs money every year afterwards. The purchase is scrutinized. The obligation it creates usually is not.

·

8 min

var(--variable-rpcX8dOAk)

Key findings

A technology purchase funded once creates costs that recur. Licensing, support, refresh and the staff time to operate it continue after the funding that bought it has ended.

Procurement scrutiny concentrates almost entirely on acquisition. The multi-year obligation a purchase creates is rarely evaluated with the same rigour as its price.

The most common failure in small-organization technology is not buying the wrong product. It is buying a correct product sized for an organization with more operational capacity than the buyer has.

Sustainment cost should be evaluated before acquisition, not discovered in year two, and it should be evaluated against the staff who will actually operate the system rather than the ones a vendor assumes.

A district receives one-time federal relief funding and buys devices. A nonprofit receives a capital grant and replaces its network. A municipality uses an end-of-year surplus to stand up a new platform.

In each case the money was real, the purchase was reasonable, and the procurement process worked as designed. Someone compared options, checked the price, confirmed the budget and signed.

And in each case the organization acquired something that costs money every year afterwards.

Devices need management, replacement and eventually disposal. A network needs support contracts, firmware maintenance and somebody who understands it. A platform needs licenses that renew, configuration that drifts, and administration that has to happen whether or not anyone was assigned to it.

None of that was funded. It was not hidden, either. It simply was not the question being asked at the point of purchase, because the question being asked was whether the organization could afford to buy the thing.

The asymmetry

Procurement processes are built to scrutinize acquisition. Competitive bidding, price comparison, board approval, funding source verification. The controls are real and they work.

Almost none of that attention is directed at what the purchase obligates the organization to for the next five years.

This is not a criticism of the people running those processes. The rules they operate under are written around acquisition, because acquisition is where the historical risk of fraud and favoritism sits. Sustainment is a budget question, and it arrives in a different fiscal year, in a different document, usually in front of a different set of people.

So the two halves of the same decision are made separately, by different people, at different times, against different criteria. And the half that determines whether the thing survives is the half nobody owns.

What it looks like in year two

The pattern is recognizable once you have seen it a few times.

Year one, the purchase is celebrated. The equipment arrives, the platform goes live, the grant reports well.

Year two, the licenses renew and the renewal is not in the operating budget. Somebody finds the money by deferring something else.

Year three, the person who configured it has left, nobody else knows it properly, and the system is running on defaults nobody chose. Or it has quietly stopped being used, and the organization is paying for it anyway.

Year four, it is a liability. It is out of support, it cannot be updated without a project, and it is now a finding on an audit or an entry on a risk register.

The purchase was never wrong. What was wrong was treating a recurring obligation as a one-time transaction.

Sized for an organization you are not

The second failure is subtler than the first, and it is more common.

Enterprise technology is designed for organizations with operational capacity. A platform that assumes a systems administrator, a security function and a change process is a reasonable platform, and it will work well in an organization that has those things.

Sold into an organization that does not, the same platform becomes a problem. Not because it is bad, but because it is correct for a buyer the purchaser is not.

We see this most often in three forms.

Capability that requires configuration nobody will do. A license tier includes advanced protection that has to be turned on, tuned and monitored. It gets bought, never configured, and the organization believes it is protected.

Systems that require a specialist to change. Every modification becomes a support call or a project, so modifications stop happening and the environment ages in place.

Tooling sized for a team of twenty operated by a team of one. The person is not underqualified. They are outnumbered by the surface area they inherited.

The vendor’s model is not your model

None of this is deception. Vendors size their products for the market they sell into, and their reference deployments assume the operational maturity that market has.

The gap opens when a smaller organization buys the same product through the same channel, often at a genuinely good price, and inherits assumptions that were never stated because they were never in question for the buyer the product was designed around.

A nonprofit with fifty staff and no IT function is not a small enterprise. It is a different kind of organization, and the right answer for it is frequently a simpler product operated well rather than a better product operated badly.

That is an unpopular thing to say if you sell technology, which is part of why it does not get said often.

Two questions about the same purchase

What procurement asks

What determines the outcome

Can we afford to buy it

Can we afford to buy it

Can we afford to keep it, every year, after the funding ends

Is the price competitive

Is the price competitive

What does it cost over five years including licensing, support and refresh

Does it meet the requirement

Does it meet the requirement

Does it meet the requirement given the staff we actually have

Is the funding source eligible

Is the funding source eligible

What happens to this system when that funding source ends

Did we follow the process

Did we follow the process

Who is accountable for operating it in year three

Which vendor scored highest

Which vendor scored highest

What does it cost to leave, and can we

What to ask before signing

Six questions. None require technical expertise to ask, and the answers are usually available before purchase if anyone requests them.

What does this cost in year three? Not the purchase price. Licensing, support, and anything that renews. Ask the vendor to state it in writing.

What happens when the funding ends? If the source is a grant or one-time allocation, name the operating budget line this moves to, and confirm it exists.

Who operates this? A named person or role, not a department. If the answer is the person who already runs everything else, that is the answer, and it should be weighed.

What has to be configured for this to do what we are buying it for? Capability included in a license is not capability in operation. Establish the gap between the two before rather than after.

What is the refresh cycle? Hardware ages out. Ask when, and what replacement costs, and whether that date falls inside any funding you currently have.

What does it cost to leave? Data export, contract terms, and whether anything is stored in a format only this vendor reads. The answer is rarely zero and is rarely volunteered.

What this means for how technology is bought

The argument underneath all of this is that acquisition and sustainment are the same decision, and separating them is the root cause rather than a procedural inconvenience.

An organization that evaluates a purchase on five-year cost, operational fit and exit position will sometimes buy something less impressive than it could afford. That is the correct outcome. The alternative is a portfolio of correct purchases the organization cannot operate, which is where a great many small organizations actually are.

This is also why we treat procurement as a technical discipline rather than a commercial one. The questions above are architecture questions wearing a budget costume. Answering them requires knowing what the product actually does, what it depends on, and what operating it involves, which is not information a price comparison contains.

What this is

This is a position rather than a finding. The patterns described here come from working with organizations that inherited technology bought on those terms, and it is offered as an argument to disagree with.

Two of the specific situations behind it are documented in our research, with sources and method stated. Those pieces are reporting. This one is not.

Sources

  1. Qwalora, “Inside the walls: what K-12 technology funding covers after the reset.” Research, September 2026. Covers the end of ESSER, the removal of Wi-Fi hotspots and school bus Wi-Fi from E-Rate eligibility, and the FY2026-2030 Category Two reset.

  2. Qwalora, “Microsoft’s nonprofit licensing change was a security change.” Research, September 2026. Covers what nonprofit organizations lost in security capability when grant licensing changed, and what closing the gap costs.

Tell us what you are deciding.