Time's up for T&M

SaaS products, code-generating AI, and increasingly desperate outsourcing megafirms combine to place Western software development agencies on death ground. There's no further margin for error. In this article we expose the increasingly dangerous hypocrisies and fallacies of time and materials software estimating, pricing, and billing. We've written this specifically to help our friends and allies begin their fight back.

Time and materials (T&M) is the professionalized jargon phrase for "pay-as-you-go" when used outside of a Boost Mobile. T&M evolved from suppliers' need to control risk and scope creep, avoiding upside-down financial commitments that could sink their entire enterprise.

Like the water a fish breathes, modern software professional services have so normalized T&M billable hours that few staff can think in any other way. It's difficult to vilify T&M for its original purpose: controlling scope creep. Instead, we attack T&M for what it's become: financial diaper armor worn to absorb the (in)consequences of poor upstream cooperation, communication, and estimation. We examine T&M's origin, its employment by software vendors, its impact on software services buyers, its resultant traumas and conditioned responses, and finish with skin-saving recommendations software services vendors should employ going forward.

Temples, mosques, cathedrals, granaries, aqueducts and other classical and medieval construction projects took lifetimes to build. Project complexity and scope variance required a flexible payment mechanism to ensure workers got theirs. Consequently, guilds and governments paid workers daily wages (time) while construction business owners procured and provided tools and supplies (the materials). T&M was born.

Industrialization refined T&M, turning labor into a measurable commodity: production output per worker per hour. Granular measurement necessitated detailed tracking, giving rise to timecards, accounting, and tracking, and the needling tyranny of metrics we know and love today. Mind those farthings and schillings, addle pate!

In the world of atoms, T&M reached primacy inside World War II America's defense contracting bureaucracy. Necessary but unpredictably complex experimental engineering projects had to happen, but couldn't be estimated. The U.S. government and its defense industry settled into a T&M engineering groove that, surprisingly, took several decades to become scandalously expensive.

In parallel, those peddling intangible work—consultants, accountants, lawyers, and other professionals—hopped on board the T&M train, selling the billable hour to justify their fees. This group started the evolution toward T&M's next instar: software.

Now in the world of bits, software development firms leveraged T&M to guide projects toward completion by applying new costs to every scope-creeping "by-the-way" request. In the 2000s, web-based software took center stage. In that space, software development as a professional service existed largely as separate departments inside of more traditional organizations like ad agencies, staffing firms, and engineering services companies.

T&M's ideological stranglehold started with the Agile Manifesto, which favored T&M explicitly because it enabled flexibility as a project evolved. That document is now officially 25 years old. Those buying custom software were likely to be as sophisticated as those engineering said software, just not at software development, and were likelier to roll with uncertainty. Similarly, those creating software were highly likely to be genuinely engineering-minded and not just library gluers or vibe-riding prompt-jockeys. There was no SaaS back then. The software industry has long since passed this era and teeters on the brink of becoming cheaper than skilled manual labor. Compute is now quite literally the cheapest resource available to a business. Time to rethink T&M.

Viewed as the ultimate shield against changing scope, relationship whims, evolving technology, staff turnover, codebase inheritance, and other forces majeure, T&M's intended to protect buyer and seller from each other's worst instincts. Defaulting to T&M and hourly billing feels as obvious as using SaaS-based accounting or project management software for day-to-day operations.

However, T&M billing immediately breaches a fundamental project boundary: desired scope may be infinite, and work may be indefinite, but client budget's not. There's always a cap.

Modern software's pro-case rationale for T&M billing

Pinning an estimated price to a custom project causes most salespeople, project leaders, and business owners significant consternation. Even with a clear scope and an accurate estimate in hand, fixed pricing feels like a needlessly zero-sum game. What if you're wrong and it blows up? What if you're right and this project's the greatest heist of the year? "If we just price this time and materials, everyone wins some." Is that so?

In an ideal world, or perhaps even software's previous world, T&M helps vendors handle clients by strapping their squishy, semi-tangible work to objective, industrial-era measurements:

• Clients pay for what they use.
• Clients pay by the standardized metric of the hour.
• Clients pay a unit profit and never feel like they're getting fleeced.

Software services time and materials billing takes a handful of primary forms:

• Resource hourly. The vendor calculates its ideal rate per resource type (QA, engineer, UX, etc.) and level (junior, senior, etc.), then bills each person at a different rate per contribution per project.
• Blended hourly. The firm takes the above and throws those numbers into a pot, whisking together a singular rate they can use to simplify messaging and sell against competitors.
• Day rates. Oldest of the old school, reduces tracking overhead and eliminates 15-minute increment-level needling.
• Unit capacity. Some vendors sell a team and that team has a weekly or monthly price and available capacity at said price. Seen most often from multidisciplinary firms who swing big and don't use bottom-up estimation methods. T&M's most abstract form.

On the accounts receivable side, vendors generally bill time and materials projects in arrears (after the fact) on a bi-weekly or monthly basis. For sales, T&M billing generates fixed profits per hour, so vendors' executives logically encourage their sales reps to sell on hourly margin above other metrics.

How T&M projects play out inside vendor organizations

T&M's core weakness doesn't show up until accounting sees the P&L statement. T&M's fixed profit per hour strangles early-project operating margin at precisely the moment when vendors need financial and staffing flexibility most. Similarly, low early margin encourages vendors to bill fast and bill hard despite the tenuous nature of early requirements. As a countermeasure, down payments provide up-front cash and help professional services providers stay cash-flow positive through the duration of a given project (in addition to signaling client commitment).

Financially, T&M projects can all work out fine without tension, but if and only if project size exceeds a certain threshold wherein the down payment margin provides enough money to absorb the sideways effort needed to adapt to scope variance. That project size is probably around $250,000. In fact, if you take the last two digits of the current year and add four zeros, that's the number. It's $260,000 as of this writing.

Trouble is, your median software development agency hasn't got the pricing power of a WWII American defense contractor or even a 2010s digital agency. With median project sizes hovering between $20,000 and $50,000 (and falling), project operating margin will be small enough that it can be rapidly erased by any concession (screwups, rework, etc.) or, critically, cash missing from any disputed or otherwise unpaid invoice.

Vendor reactions to buyer T&M defenses

Buyers typically manage T&M risks in two places: before (caps/NTE) and after (disputes). During the project, they leave budget accountability to the vendor, a fact few vendors realize. Here's how vendors cope with both mechanisms.

Prevention: capped T&M

Large corporations can still pay for six- and seven-figure software, but they have their own T&M countermeasures. NTE (not-to-exceed) limits levied by purchase orders specifically guard against runaway costs. Yes, the dreaded capped T&M.

"Capped T&M limits our upside gives us unlimited downside!" — Every software services executive ever

Perhaps. In truth, your client has told you what your work is worth.

Vendors accept capped T&M deals because the buyer's somehow irresistible. An international brand, a prestige project, a large deal, etc. Buyer procurement methods and policies apply pressure to vendors' pricing power and vendors usually just…buckle. Then rationalize.

When the project ends and reaches its budget cap, the buyer applies further pressure to reach a conclusion, and the project runs over internally, draining whatever margin was earned. Again, vendors generally just metabolize this in hopes of winning the next phase of the project.

Cure: disputed invoices

Ironically, T&M helps buyers dispute invoices. "What was so-and-so doing server config for 15 hours? I'm not paying until you sort this out."

From a tax perspective, vendors can write these off. Unfortunately, any amount of missing cash requires most to dip into the line of credit to make that cycle's payroll. Worse, when buyers drag their feet after a dispute, said challenge creates an unhealable relationship injury and the vendor will eventually find a way to fire the buyer.

Software services buyers wrestle with two harsh truths:

1. A software solution only has a certain amount of value to their business. If its build cost exceeds its value, there's no point in doing it.
2. Despite many software applications similar to their desired solution already existing, the exact thing they want probably hasn't been done before. Therefore, most professional services firms built their businesses on figuring it out instead of knowing.

How are they supposed to win at buying custom software?

T&M makes shaky starts shakier

Buyers begin by walking into an uncertain situation with a high need for certainty. From the very onset, all those sensible vendor offerings meant to de-risk and clarify projects tragically increase uncertainty by building a concrete wall of Rumsfeldian certain uncertainty (a.k.a. "discovery") in front of the uncertain certainty of code that does things—any things—good, bad, right, and wrong. The buyer handed this problem to the vendor and wants enough confidence to step away. To "discover" is to deliberately remove project traction precisely when the buyer needs to feel on course.

T&M only adds to this uncertainty. Buyers put up with it for four reasons:

1. They haven't got a clue how much their application should cost.
2. As a safety valve to prevent extortion by the salesperson.
3. Combining T&M with an NTE limit creates a container for any budgetary mess. Buyers rarely think about the potential "upside" of vendors coming in under—staunching overruns takes precedence. More on that later.
4. For buyers managing projects themselves, timesheets provide pseudosurveillance data documenting that a vendor's billable resources actually perform valuable work. It doesn't matter that timesheet fidelity and accuracy varies greatly by individual. Clients only nitpick timesheet data if vendors piss them off.

Oftentimes vendors think buyers require T&M because they're comparing rates when they make a purchase. In our experience this happens infrequently during new project bidding but becomes more common as a project ages. Rate comparison typically happens in the middle of a project when two lines invert and intersect:

1. The buyer's increasing understanding of their own project breaks a threshold and becomes holistic. "Now that I know what I need I can get it cheaper."
2. The vendor's delivered value declines as they settle in a bit too much and they start to feel expensive.

Even when things are well underway, it's difficult to express the awkward unease a buyer feels when they receive their first invoice for an unpredicted amount. "We're flying. Will we land?"

T&M at the end of a project

When the clock runs out and the budget has been reached, we arrive at the moment where T&M makes drastically less sense for buyers, bringing T&M's two greatest buyer weaknesses hurtling to the fore: doneness and quality.

Reaching "done" under T&M

Allow me to prompt you.

Become a lead engineer at a software professional services vendor. You've just finished coding and testing the application your client contracted you to build. It functions flawlessly, looks great, and you even beat their tight deadline by a few days due to some extra hours put in by your rockstar devs. All systems are go and you're ready to chill this weekend. You're currently on a conference call with the client's primary stakeholder walking them through their shiny new application.

Then it comes.

Stakeholder 1: "Where's that thing we talked about four weeks ago?"

Lead engineer: 😯

As a vendor's delivery team rushes toward the finish line, they tend to lose sight of where it is. Whether due to miscommunications, lack of communications, misprioritization, or plain old spacing out and forgetting, features invariably get missed. Their absence goes unnoticed until the end—exactly when there are no more hours available.

Vendors also regularly misconstrue "done" with "feature complete". To every buyer, "done" means "usable right now", but to most software professional services vendors, "done" means "code written". A recent real-world conversation we just heard:

Vendor: "New Application is innovative!"
Buyer: "No it's not. It's sitting in a repo."

Vendor: "Look at X feature. It does exactly what your users need now, not like the old garbage."

Buyer: "Can I use it in my business right now?"

Vendor: "Wellll…."

When vendors run out of budget, buyers run out of leverage in a T&M world. Now the pain fully sinks in and buyers:

1. Think they'll never reach "done".
2. Believe their vendor has no incentive to reach "done".
3. Feel eternally milked.

But wait, there's more.

Quality under a T&M regime

After receiving their freshly-built software application, a typical buyer can't measure or know much about the application itself, only its delivery:

1. Did you do it on time?
2. On budget?
3. On scope?
4. Can I use it right now?

Obviously if a vendor misses these it doesn't matter if they write amazing software. Even when delivery went well, few buyers can ever know if their vendors' code was any good without a third-party audit.

When the buyer does discover a quality issue that wasn't caught by the vendor's QA screen, the project may have concluded already, either officially or because the budgetary well ran dry. T&M leaves them with no recourse except paying more or asking pretty please. To cap it off, many post-launch issues with a software application are non-functional, yet most SOWs focus entirely on the software's functionality. Stuck here, the buyer can't even point to the contract for remedy, leaving them:

1. Angry that the standard of doneness they're held to isn't the standard they can hold their vendor to.
2. Feeling like a hostage.
3. Feeling nickel-and-dimed.

Bitterness after the fact amplifies the custom software trauma buyers have known for decades now. If you're a vendor and it feels like your clients are always trying to be rid of you, decades of conditioned trauma—some of which you may have perpetrated—explains their motivation. Product, AI, and outsourcing alternatives are the rationale, the interminable suckage of software development is the true reason.

Strip away every shred of history and muscle memory and T&M perpetrates one core crime against the modern buyer:

"I planned for one number but the price changed to another, higher one."

Cathedral builders used T&M cover a day's work on a century's project. Agile adherents advocated T&M as a method to help roll with engineering change, but T&M gradually became a service delivery model designed to cost against change, protecting the vendor's here-to-there vision of the project at their client's expense at the exclusion of their client's later realizations.

T&M creates the weirdest and most toxic behaviors in everyday, normal-person, non-Silicon Valley tech. Like heavy armor, T&M impedes the vendors wearing it. If they meet or come under budget without penalty, they cap their own profit potential, and the concluded hours limit opens the door to an uncertain client satisfaction level post UAT or post launch. If they exceed hours, they blow the budget and piss off the customer, lose their trust, and trigger a funding evaluation and possible political recriminations. Overage money was never there.

Every T&M sale is infinite, but every T&M purchase brings hard constraints.

Solutions predicated on both barriers and fantasies

When T&M projects start wrong, it's often because the vendor can't determine a moderate or logical way to deploy the client's money. Generally, this happens because they refuse to treat customer money like it's their own, preferring nuclear solutioneering instead:

1. Technology zealotry. Some professional services vendors believe their solution so important that they must operate in an unconstrained way.
2. Goldfishing. Buyers know that if they answer "what's your budget?" the vendor will figure out something that fits in X. They don't know if that's the right thing or the right way.
3. Arbitrary cuts. Vendors cut scope to fit budgets, sometimes without thinking the consequences through, chopping out vital elements. As we heard from one client scolding their vendor "Cutting that feature means you understood my need and deliberately chose not to fulfill it".

Most vendors know better, but some old school strategists still believe digital tools create limitless value because they lack the replication costs of physical goods. They're operating under some starry-eyed Fast Company glamor wherein digital makes infinity tractable: infinite scale, infinite growth, infinite profit. Infinite spend creates infinite earn, right? T&M matches this infinite proposition.

Who's missing from that conversation? The buyer per usual.

Fallout when budgets exceed their allotment

When a T&M software development project exceeds its allocated budget, the breach causes a chain reaction inside the buyer's organization. Vendors, pay close attention to this section.

Your PO overage broke the piggy bank. Only the piggy bank wasn't yours, your stakeholder was responsible for it. When it shattered, you also broke the following:

• Customer trust. Budget breaches tend to come without warning. "Didn't we pay more for these guys because they wouldn't screw up? I thought they had done this before!"
• Customer narrative. Your workstream was green in their weekly slides until right now. You broke their show. "Why is everything green until it's red!?"
• Stakeholder freedom. People formerly interested in line level budget now interested in detail. "Are you kidding me? Now I have to go to finance meetings!

Don't think for a second that because the client makes a certain publicly-recorded profit that they have money for you. The real or imagined size of the budget's immaterial if you break the piggy bank. The infinite proposal exists, the infinite PO doesn't.

Your stakeholder must now supplicate themselves before a rogue's gallery of colleagues because you messed up. They're about to jump through several hoops on your behalf, which to be clear, they're doing because delivering the project they've contracted to you deliver keeps them employed:

1. Bargain. They'll interrogate you looking for a way forward that doesn't involve doing the rest of the steps. "Maybe you can cover it from another PO or push this billing into the next phase?"
2. Apologize. Now your stakeholder looks like a jackass thanks to you. Hopefully they've got some social credit to burn.
3. Deflect. The blame game begins. Your stakeholder will eat a little shit and so will you. For first-timers this doesn't tend to last long, but if it happens again it'll get messy.
4. Report. Anyone watching needs to know, so it's time to show the boss and get whacked by their rolled up newspaper.
5. Scour. It's possible but unlikely that they've got the cash in their own budget. If they do, it'll require them reallocating from something else to pay you.
6. Beg. Many projects impact multiple teams, sometimes those teams have additional cash they can contribute to cover an overage.
7. Cut. Depending on the project's importance, your stakeholder may completely cut something (or someone) to make up the overage. "I was going to fire so-and-so anyway…"
8. Doubt. Finding the money isn't the end of this. You're being watched and even if your stakeholder likes you, they won't stick their neck out for you with their colleagues after you've misbehaved in a way that affects your stakeholder's status in front of their peers.

Your overage put your stakeholder and their organization in an ugly position, so ugly things will happen. If they agree to bump the PO, your client isn't handing you another piggy bank full of cash. At best, they're grabbing duct tape they can use to either fix the piggy bank or tape your hungry mouth shut.

Empathy that's always missing

Virtually no client environment operates in an uncontrolled T&M paradigm. If you're a vendor and your customer works with atoms instead of bits, they don't see the world like you do. No broad estimates, no backlogs, no story points, no tickets, no randomly-sized or -timed invoices. Hard dates, clear deliveries, declared dollars, and penalties for screwing up.

Software T&M starts by ignoring or dismissing the client's probable context. This gets exceedingly difficult when the buyer needs the vendor's custom software to fulfill their own obligations. Buyers become a liability interpreter struggling to bridge their customer's clear and certain need with their vendor's non-committal fulfillment method. The buyer's on the hook if the customer bails or if the vendor can't adequately deliver.

It's equal parts fascinating and appalling that this is even possible. Why does T&M exist like this?

Absolution down the line

There's nothing humans seem to despise more than accountability. Fortunately, T&M billing absolves several groups of toxic accountability:

1. Estimators have a pressure relief valve in case they're wrong.
2. Designers and consultants feast on the budget when it's at its largest.
3. Developers and testers shield themselves with concrete numbers.
4. Delivery leaders feel honest when clients pay for what they use.

At last we arrive at T&M's true psychological value for vendors: T&M makes project managers and salespeople the bad guys when things go wrong. If you parlay a missed feature into a budget problem, then designers, engineers, consultants, and testers—the hitherto non-expendable hard-skill staff—walk away scot free.

We've witnessed software services vendors violate client trust time and again. At some point, every digital services buyer has been exploited, and we'd argue that all clients of digital firms have been traumatized to the max.

Part of AI's promise is that businesses can move software development fully inside the company, removing outsiders' power to traumatize them and ravage their budgets. Even better, they can oversee it with their industry experts instead of hiring legions of technology experts. While the classic 1990s IT extortionist is long extinct, the combination of alternatives—AI, outsourcing, and SaaS—let the ponytail guy take care of nearly all of the business's tech needs.

Death is a choice

Vendors, you're still in business, but you've long since ceased being the only game in town. Buyers still need you, but you're battling for their precious trust against their conditioned rage and their prospective alternatives. Hope exists because:

1. Nobody trusts AI to handle all software development autonomously. Blood-drinking billionaire techbros earn money, not trust. You do that. Clients need someone they can trust to yoke the god-machine.
2. Nobody feels like SaaS is a great value anymore. $75/seat for a labyrinthian tool that adds as much work as it relieves and is so complex it creates bloviating industry experts? Terrible. Paying 100% to use 10% of the software? Even worse (ahem, QuickBooks Online).
3. Nobody actually wants to outsource software development. Everybody hates dealing with body shops and code mills and their unremarkable, debt-laden outputs. Buyers only do it because of the massive wage differential on low-stakes software projects.

How can vendors strike back?

Concrete steps firms can take today

Like all personal growth seems to, moving on from T&M's tragedies means breaking your own chains. That starts early in the software services sales cycle but requires some adjustments throughout:

• Plan vs. buy. Understand what your prospect's doing with numbers. Are they planning or buying? If they're planning, ranges work to help them allocate funding from a larger block. If they're buying, use concrete, estimated numbers you can explain. fixed numbers. If both, use both.
• Estimate professionally. Buyers, vendors, gather round. There is a correct answer on how long it'll take to create your software. Trouble is, you'll find out once it's built. But good news! Use your giant brains to bring building forward. First, pick criteria for an opportunity worth your thought. Second, elicit enough requirements about the thing. Third, then think through how you'd build the thing and price against that. Estimation was never about the price or the proposal—it's always been about winning trust.
• Fix prices frequently. We recommend attaching fixed prices to removable problems. "We'll add your store location map for $5k. Build, test, insert, deploy, verify. Sound good?"
• Price like you'd buy. $40k for code intake wasn't absurd in 2022, but sounds ridiculous in 2026.
• State best cases, too. As we heard a client tell a provider, "Give me your best case scenario and tell me when it's going wrong! Don't give me your worst case scenario by default and try to undershoot. I'm mature enough to be part of this discussion." Our client didn't realize that the core reason nobody best-cases him is that nobody put in the effort to estimate multiple scenarios.
• Actually engineer. Put your thinking out there and deliver the one thing no alternative can. Don't fall into the "developer" trap shilling highest common denominator costs with lowest common denominator people. We've encountered firms with hundreds developers and not a single engineer in sight.
• Avoid avoidance. Most avoidance comes from fear of broaching difficult subjects or fear of stalling work before "inevitable" momentum builds If your estimate was off, it should be because you missed something or missed its magnitude. Problems you spot but avoid metastasize into project-lethal issues.
• Change delicately. Project change isn't license to ask for more money. Inability to manage budget change reflects an inability to manage software development over time.
• Don't sell with AI. Estimation is your first and best opportunity to think the project through. You'd rather the rubber met the road earlier in the cycle instead of passing the thinking buck down to UAT. Additionally, buyers soliciting multiple bids will certainly get back very similar-sounding results from vendors' AI-generated proposals. "But we built these using our source documents!" Irrelevant—this is about the thought, not the document.
• Apply AI carefully. Proactively insert AI into your project plan. Don't let the client trip you up here. You're the software professional with the expert opinion on how code-generating simulacrum machines can be best used to create and manage the thing they want.

Fighting back means transforming into an alternative to your previous self.

Value has long been custom software's weakest link. If you need to build valuable software instead of perfunctory software, contact Next Mile to bring immediate clarity.