Lowest Priced Technically Acceptable (LPTA) Contracts Are Sabotaging DoD Software Delivery

I’ve seen this play out more times than I can count.

A critical DoD program needed a modern, secure software platform to replace a legacy system. The solicitation went out as Lowest Priced Technically Acceptable (LPTA). The winning bid came in significantly below the government estimate, seen as a win for the Government evaluators to drive down costs.

And it was.

Within months, the cracks showed. The contractor couldn’t recruit top-tier engineers at the cut-rate salaries they had bid. Senior developers bailed for better-paying roles. In their place came less experienced staff, bright but green, thrown into a mission-critical codebase they didn’t understand. Deadlines slipped. Defects piled up. Morale tanked.

By the end of year one, the government had burned through change orders, scrambled for surge staffing, and was quietly paying more than they would have under a best-value contract. The schedule was in shambles, the operators had lost confidence, and the “savings” were a mirage.

The Usual Suspects: LPTA Pitfalls in Software Delivery

Anyone who’s been in the trenches knows the pattern:

• Resume Mills – Proposals padded with impressive résumés for people who never actually show up on the contract.

• Bait-and-Switch Staffing – Senior engineers in the bid replaced with junior hires after award to hit profit margins.

• Paper Compliance – Teams meet the letter of the requirements while ignoring the spirit of mission readiness.

• Churn and Burn – Staff turnover so high that the program is perpetually onboarding new developers instead of delivering features.

• Death by Change Order – The “cheap” award turns into an expensive mess once the rework starts.

These aren’t one-off mistakes; they’re the inevitable side effects of using LPTA for complex software development.

Why Acquisition Teams Keep Pulling the Trigger

I get it. LPTA feels like the “easy button.” Evaluations are faster, protests are less likely, and award timelines shrink. But software isn’t printer paper or janitorial supplies. You’re not buying a commodity. You’re buying a team’s ability to think, adapt, and deliver under changing conditions.

When you chase the lowest price, you choke off the very talent that makes software delivery successful.

The Self-Inflicted Wound

For software, LPTA is like selecting the cheapest surgeon because they technically meet the minimum medical credentials. Sure, they can operate, but do you want them leading a high-risk, high-stakes procedure?

Acquisition leaders who use LPTA for software are shooting themselves in the foot. Initial “savings” evaporate into overruns, delays, and loss of trust from the people who depend on the system.

From the industry side, it’s demoralizing to watch this cycle repeat, especially when the stakes are mission-critical systems for national defense.

A Better Way Forward

Programs need to make best value trade-off for software the standard, and not just doing best value in name only but actually operating as LPTA. Programs need to balance costs against technical excellence, prior performance, and the proven ability to deliver quality at speed. That means:

• Rewarding vendors who invest in and retain elite technical talent

• Accounting for the volatility and complexity of software requirements

• Reducing risk by incentivizing stable, high-performing teams

• Judging proposals on more than just “meets minimums”

Bottom line: LPTA in software isn’t frugal. it’s reckless. If we want mission success, we have to stop treating software development like a commodity and start valuing the people who build it.