Choosing an engagement
Managed support vs project warranty
A project warranty covers defects in the software that was delivered, judged against the original project agreement, for the period that agreement sets. Unless the agreement says otherwise, it usually does not assign anyone to watch the system, respond to incidents, apply dependency and security updates, or adapt to changes in the platforms the software relies on.
Managed support is a separate, ongoing service that takes on agreed operations, maintenance, and improvements for a live system, with covered systems, coverage hours, and escalation written down.
If your own team will operate the system, the warranty plus your team may be enough. If customers or daily operations depend on the system and nobody on your side can or should own its care, agree on managed support before the warranty ends.
What a project warranty covers
A project warranty covers qualifying defects under the delivery agreement. It gives the buyer a route when the delivered software does not match what was agreed.
Terms vary by contract, so read the actual clause. Check which defects qualify, how they are reported, how remedies are handled, and what the agreement excludes.
Common exclusions to check include new features, changed requirements, problems caused by third-party services or platform updates, changes made by someone else after delivery, hosting outside the delivery team’s control, and day-to-day user support or training.
A warranty gives both sides a reference point for qualifying defects. It does not operate the system after launch.
What managed support covers
Managed product support is ongoing ownership of agreed software operations, maintenance, and improvements after launch. A live system still needs care when there is no defect in the delivered scope.
Managed support operations usually begin with a system health review: application, infrastructure, known incidents, access, and operational risks. From there, the agreement can define alerts, triage, escalation, maintenance, updates, performance reviews, and corrective work.
It can also include improvements within the agreed support scope. Substantial features, migrations, and architecture changes need their own scope, even when the support team supplies useful context.
Write down covered systems, coverage hours, incident priorities, response expectations, escalation contacts, and reporting. Service levels and any out-of-hours coverage must be explicit. Do not assume commitments that nobody has agreed.
Compare by responsibility
Compare the responsibility each agreement assigns.
What it is
Project warranty: A commitment inside the delivery agreement.
Managed support: A separate, ongoing service agreement.
What it covers
Project warranty: Defects in the delivered scope, against the original agreement.
Managed support: Agreed operations, maintenance, and improvements for a live system.
When it runs
Project warranty: For the period the delivery agreement states.
Managed support: For the term of the support agreement, reviewed as the product changes.
Monitoring and incidents
Project warranty: Not assigned unless the agreement says so.
Managed support: Alerts, triage, escalation, and incident handling as agreed.
Updates and third-party changes
Project warranty: Usually excluded when the delivered code is not at fault.
Managed support: Dependency updates, security fixes, and platform changes within scope.
Changes and improvements
Project warranty: Treated as change requests.
Managed support: Improvements within the agreed scope. Larger work is scoped separately.
Coverage hours
Project warranty: Not a coverage commitment.
Managed support: Coverage hours and response expectations written into the agreement.
What your team keeps
Project warranty: The accepted software and its delivery records.
Managed support: Runbooks, change records, and unresolved risks kept available to your team.
Fits when
Project warranty: Your own team operates the system.
Managed support: Customers or operations depend on the system and your team can’t or shouldn’t own its care.
Contracts vary. Check the warranty clause and the support agreement for the exact coverage and exclusions.
After launch: defect, change, operations, or new work?
After the build is accepted, the warranty period runs for defects. Some agreements add a short stabilization period, sometimes called hypercare or early life support. Check what that period covers. It does not decide who owns the live system unless the agreement says so.
Someone has to own the system after launch: your team, a managed support provider, or nobody by default. The gap appears when a real problem has no agreed category.
Defect
What it looks like: The delivered software does not behave as the agreement specified.
Usually handled by: Under the warranty, if it is still in force.
Change
What it looks like: A request to behave differently from what was agreed, including small adjustments.
Usually handled by: A change request under the build agreement, or an improvement within a support scope.
Operations
What it looks like: Keeping the system healthy, including alerts, incidents, dependency and security updates, certificates, capacity, backups, and fallout from third-party or platform changes.
Usually handled by: Your operating team or managed support.
New delivery
What it looks like: A substantial feature, migration, or architecture change.
Usually handled by: A separate delivery scope, such as product engineering or FDE.
Use the agreements and acceptance criteria as the reference.
Name a person on each side before launch and agree how a disputed issue is settled. Use the build’s acceptance criteria as the reference for defect claims. Without that, the first serious incident can become a contract argument.
Close the operating gap before the warranty ends. Name who watches alerts, applies updates, answers users, reviews access during an incident, and approves production changes. If nobody can answer, the system has an ownership problem.
For a live system, assign defects, changes, operations, and new delivery separately. AI evaluation and model behavior need their own operating scope.
Supporting a system another team built
UCS can assess an existing product for support through a health and risk review. Documentation, access, dependencies, incident history, and any required remediation inform the coverage agreement. The review does not promise coverage by itself. Use the same approach to review an AI-built product before taking it on.
Prepare a system map, current runbook outline, sanitized incident patterns, required coverage hours, the service decision owner, and the access and escalation approver. Bring enough context to understand the live system without sending restricted material.
When the original warranty is still running, defects in the delivered scope may still belong to the original delivery team, while operations belong to the support owner. Agree who receives each type of issue, how the teams coordinate, and that neither makes uncoordinated production changes.
A health review may find gaps that need fixing before support can accept responsibility. Missing monitoring, untested recovery, unclear access, or access held by a former vendor can be blockers. Choosing or exiting a build vendor is covered in the guide to fractional CTO vs tech agency.
A decision checklist
Use these questions with the product owner, whoever runs operations today, and the delivery partner.
What does your warranty clause actually cover?
Read the defect definition, reporting route, remedies, exclusions, and end date. Write down anything that is not mentioned, and get qualified advice where needed. For delivery that includes AI, see how to write acceptance for AI features.
Who operates the system after launch?
Name who watches alerts, handles incidents, applies updates, and answers users. If the answer is the delivery team informally, that arrangement ends with the project unless a support agreement says otherwise.
What coverage does the business need?
Decide covered systems, coverage hours, incident priorities, and escalation contacts from how customers and operations use the system. Do not assume expanded coverage.
How will you classify a disputed issue?
Agree who decides between defect, change, operations, and new work. Use the build agreement and acceptance criteria as the reference, and record the route before an incident tests it.
Is your own team ready to run it?
If the team can release a change, recover from a failure, and find the operating records, the warranty plus your team may be enough. If not, build that capability or agree on managed support.
Is there new delivery hiding in the support request?
If the list includes substantial features, a migration, or architecture change, scope that work separately. Support should not quietly become a new build without acceptance criteria.
Your team will operate the system: warranty plus internal ownership can be enough. Check the exclusions.
The business depends on the system and nobody owns its care: agree managed support before the warranty ends.
The warranty is still running: route defects and operations separately, with production changes coordinated.
Substantial new work appears: neither warranty nor support is the right container. Scope delivery separately.
When another engagement fits better
Your own team: if your team can operate the system, warranty plus internal ownership is a sound choice. Keep the runbooks and change records with the team.
Reverse FDE: when you want your operators to take over care, with practice first. Reverse FDE is UCS’s name for preparing operators through shared delivery.
New delivery: for substantial features, migrations, or modernization. Use FDE when delivery needs close access to users and systems, or product engineering when the product outcome needs coordinated delivery.
Dedicated team: when the post-launch need is a continuing roadmap, not care of a stable system. A dedicated development team can provide sustained capacity.
Fractional X: when the gap is longer-term technical direction for the product. Fractional X can own agreed leadership decisions.
AI systems: start with AI product engineering when the issue is the application, workflow, and production boundary around AI.
Bring the system and its support boundary
Bring a system map, warranty clause summary and end date, current runbook outline, sanitized incident patterns, required coverage hours, the service decision owner, and the access and escalation approver.
Do not send credentials, confidential logs, production data dumps, or confidential contracts. Describe the boundary first, then agree what can be shared.
You can also email hello@ucs.tech with a short description of the system and support needs.
Questions before we start
What does a software project warranty usually not cover?
Warranty terms vary, but common exclusions include new features, changed requirements, third-party services or platform updates, and changes made after delivery by someone else. They usually do not assign monitoring, incident response, or user support. Check your own agreement.
Does a project warranty include monitoring or incident response?
Usually not, unless the agreement says so. Monitoring, incidents, and updates need an operating owner, either your team or a managed support agreement.
Should managed support start during the warranty or after it ends?
It can start during the warranty to avoid a gap in operations. Agree which issues go to the warranty holder and which go to the support team, and how the two coordinate production changes.
Who decides whether an issue is a defect or a change?
Name a person on each side before launch and use the build’s acceptance criteria as the reference. Agree how a disputed issue is settled, so the first incident does not become a contract argument.
Is managed support the same as a maintenance retainer?
The terms overlap and providers use them differently. Compare responsibility for covered systems, monitoring, incidents, updates, improvements, coverage hours, and escalation.
Can managed support cover a system another company built?
Yes, after a health and risk review of documentation, access, dependencies, and incident history. The review may identify remediation needed before coverage starts. If the original warranty is still running, agree how defects and operations are routed.
Do we need managed support if our own team runs the system?
Not necessarily. If your team can release changes, recover from failures, and handle incidents within the needed coverage, the warranty plus internal ownership can be enough. Managed support fits when that care is beyond what your team can or should own.