AI ERP with agents inside the systems you run
AI phone and voice agents for real calls
LLM.coPrivate, self-hosted LLM deployments
Legal AI infrastructure for firms
AI RFP discovery and response drafting
Automatic.coBusiness process automation
CyberAttack.aiThreat detection and defense
Secure AI virtual data rooms
DigitalSign.coAI-designed digital signage for any screen
hardware.coCustom AI hardware, software, and engineers
Data.coPrivate AI infrastructure and governance
What Breaks in the First 90 Days With a New Software Vendor
The first 90 days with a new software vendor are where the SOW gets tested against reality, and most of the money you lose is lost here. That stops being true only when the contract was written against a discovery deliverable instead of a scope promise.
Five failure modes show up repeatedly between signature and first production release: discovery drift, environment access delays, change orders that reopen the price, QA and DevEx bottlenecks, and architecture ownership nobody claimed. For each, the fix is a specific clause or cadence to lock down before kickoff.
The dollar impact is real. McKinsey and Oxford's study of more than 5,400 large IT projects found they run 45% over budget and 56% below predicted value, with 17% so bad they threaten the company's existence. Most of that damage is seeded in the first quarter.
Discovery Drift Starts Before the First Sprint
The SOW you signed was priced against assumptions nobody has validated yet. On fixed-bid work, the vendor's incentive is to hold the estimate; on time-and-materials, yours is to question every hour. Both of you discover in week two that the integration surface is larger than the sales call implied, and that the client's "simple" reporting requirement actually spans three source systems.
Make discovery its own paid deliverable with its own acceptance criteria. Two weeks, a concrete artifact (API contract draft, data model, test-data plan, prioritized backlog with story-point estimates), and a go/no-go gate before build. The cost of a dedicated team is high enough that paying for two weeks to retire scope risk is cheap. Panorama Consulting's 2024 ERP Report found 55% of implementations exceeded budget and 68% ran past schedule, with unexpected technology needs and missing staff and skills the top reasons. A real discovery sprint surfaces both; a rushed one papers them over.
The clause worth adding: the build SOW is void if the discovery artifact names scope the original pricing cannot cover, and either party can rebase the estimate before build starts. That turns discovery from a formality into a decision gate.
Environment Access Is a Timeline Risk, Not a Ticket
The single most common week-two failure is a vendor engineer waiting on SSO, repo access, a sandbox tenant, or anonymized test data. It looks like a ticketing issue. It is actually a staffing and budget issue, because the burn rate does not pause while IT provisions.
Write an access schedule into the onboarding plan with named owners and dates. Minimum: identity provider and repo access day one, CI runners and sandbox credentials day three, representative test data and a staging environment before sprint one. Anything that requires a security review (pen-test credentials, prod-shaped data, a cross-account IAM role) needs its review started at signing, not at kickoff.
Change Orders Reopen the Price Faster Than the Scope
Three sprints in, somebody discovers that a connector the SOW named is deprecated, or that the auth flow the design assumed is blocked by a compliance review. The vendor raises a change order. The question is not whether it is reasonable; it is whether your contract makes it reviewable in days instead of weeks.
Define a change-order protocol in the SOW with a 48-hour turnaround, a named decision-maker on each side, and a pre-agreed hourly rate for scope additions. Cap the aggregate change-order value at a percent of contract (10% to 15% is typical) before a joint re-planning session is triggered. For integration-heavy builds, publish a separate API integration cost schedule by connector family, so a new SaaS source does not reopen the whole estimate.
The posture to avoid is the one where every change order feels like a renegotiation. That is a sign the SOW priced the work without pricing the uncertainty, and adversarial supplier dynamics start here.
QA and DevEx Become the Bottleneck Nobody Scoped
By sprint four, feature velocity looks fine, but nothing is getting to staging. The bottleneck is almost never code. It is one of: who writes tests (vendor dev, vendor QA, your QA), who signs off on acceptance, who owns the deploy pipeline, and who has production credentials. If the SOW did not name those four roles, the vendor assumed one allocation and you assumed another.
Set the following in writing before the first sprint:
- Test pyramid ratio the vendor commits to (unit, integration, end-to-end), measured in CI coverage
- Who runs UAT, how long each cycle takes, and the SLA on your side for defect triage
- Deploy ownership — vendor deploys to staging, client deploys to production, or a shared runbook
- Access controls on prod credentials, including break-glass accounts and audit logging
Vendor access is also a security line item. Verizon's 2024 Data Breach Investigations Report found 15% of breaches involved a third party, a 68% jump year-over-year driven largely by zero-days in vendor software. If you are modernizing anything that touches regulated data, treat the DevEx plan as part of the threat model, not a logistics appendix. Teams planning a legacy modernization often skip this because the old system did not have it; the new one must.
Architecture Ownership Is the One Nobody Writes Down
The last 90-day failure is the one you only notice in month four. Somebody chose Postgres over DynamoDB, pgvector over a managed vector store, a single-tenant deployment over multi-tenant. The decision is reversible for about six weeks and then it is not. The SOW named a stack. It did not name an owner.
Name a technical decision-maker on each side with veto authority on architecture-level choices, and require an ADR (architecture decision record) committed to the repo for anything that touches data model, tenancy, auth, or inter-service contracts. For AI work, extend the ADR requirement to model selection, retrieval design, and the prototype-to-production path, because those decisions quietly bake in recurring cost for the life of the system.
Mitratech's 2024 study found 61% of organizations reported a third-party security incident in the past year, a 49% jump, and 89% expect an audit finding on third-party risk they cannot promptly resolve. A lot of that is architecture ownership that never got assigned: the vendor shipped, the client accepted, and no one on the inside could explain the trust boundaries six months later. Pick a partner — a good question to ask on the first vendor call — that volunteers an architect for your side of the table, not just theirs.
What Shifts Over the Next Year
The change most likely to reshape this decision in 2026 is the collapse of the old scope-pricing model under AI-assisted delivery. Vendors are already pricing against generated code they did not write and estimates they cannot calibrate, and the first-90-day failure pattern is tilting toward QA bottlenecks and architecture drift rather than discovery drift. The contract clauses that protect you are moving with it: discovery-as-deliverable, access schedules, bounded change orders, named architecture owners. Sign nothing that does not name all four.
