If an API or other service an app depends on changes after launch and the app stops working, is the repair usually included in the original project, or billed separately? And how do you handle a fix that takes very little time but requires specialized knowledge?
Who pays when a third-party API change breaks an app?
Asked by
_murmur.8
Answers
Spell out the boundary in the agreement. The original price can cover building and testing the agreed features, but it generally does not mean unlimited future maintenance. If a third-party provider changes its API after handoff, that is usually new work unless the contract says otherwise.
You can offer a defined post-launch period for defects in your own work, then quote maintenance hourly or through a retainer. Be clear about response times, what counts as an emergency, and whether third-party changes are covered.
Reply to this answer
For a one-off job, I would treat post-handoff changes as a new engagement. If they want ongoing support, offer a maintenance agreement with a stated rate and a clear minimum charge or billing increment. That minimum can account for context switching, investigation, and reserving time, not just the minutes spent editing code.
Agree on the terms before doing the repair. A short fix should not be presented as several hours of work unless the contract has a minimum that was already disclosed.
Reply to this answer
There is no single standard here. Some developers include a limited warranty window for problems in the delivered work. Others consider the project complete once it has been accepted and tested, and charge for later maintenance. Either can work if the scope and duration are explicit.
For external services, I would also tell the client that API providers can change or discontinue things, and that ongoing compatibility work is separate from the initial build.
D6~Pannier:
That distinction helps. The agreement should say what the warranty covers, not just give a vague promise of support.
Reply to this answer
If the client needs reliable help quickly, a retainer can make sense. Define what it buys, such as a set amount of maintenance time or a response target, and what gets billed beyond that. A retainer should not quietly imply unlimited fixes.
If they do not want ongoing support, they can contact you when something breaks and approve a separate estimate. Either way, make sure emergency availability and rates are agreed in advance.
Reply to this answer
Add your answer
Answers are reviewed before publication.
_murmur.8:
Would you distinguish a bug in the original integration from the provider changing the API?
35Buckleup:
Yes. A defect against the agreed requirements is different from an external change after acceptance. Write down how each is handled so neither side has to guess later.