Put maintenance in the contract before month two

The short answer

An automation that passed acceptance will still break, and usually not because of the freelancer’s code. A login expires. A connected app changes. A usage limit is reached. Your own process moves on. None of that is anyone’s fault, and all of it is cheaper when the agreement already says who fixes it, how fast and at what rate.

Agree six things before you place the first order, while you still have something the seller wants: what counts as a fix, how fast they respond, the rate, for how long, what access they keep, and what happens if they stop. The same six fit on the workflow automation brief as its last line.

Why this is harder than it looks

When the build is fresh, maintenance feels like a later problem. The seller is responsive, the automation runs, and asking about breakage sounds like distrust. So it is left out.

Month two is when it matters. By then the seller has other clients, the conversation has gone quiet, and your first message is “it stopped”. Without terms, that message opens a negotiation: is this a bug or new work, is it urgent, what will it cost. You are negotiating while the thing you paid for is not running.

The same "it stopped" in month two

What happens next depends on whether the terms were written down before the first order.

No terms agreed

"It stopped"→Bug or new work?→Is it urgent?→What will it cost?→Still not running

Six lines agreed up front

"It stopped" + log line→A fix, per line 1→Agreed response time→Small invoice ✓

The four ways a working automation breaks

These all happened to jobs I run for myself. None of them was a bug in the original code.

Four ways a working automation breaks, with no bug in the code

Common

1. Something it depends on changes shape

• Posts published with one part silently missing
• Every run looked successful

Common

2. A credential expires

• Job kept starting on schedule, did nothing for two days
• The error sat in a log nobody reads

Grows with every AI step

3. A limit is reached

• Overnight job hit a monthly spending limit
• Other jobs on that account hit the same wall

Needs investigation

4. The source behaves differently

• A site loaded some reviews twice
• A count that was too high got published

1. Something it depends on changes shape. I changed the format of the posts my publishing pipeline produces. The scheduled publisher still expected the old format in three places. Nothing crashed: it would publish each post with one part of it silently missing. That is the dangerous kind of break, because every run looks successful.

2. A credential expires. A code-hosting token expired and my publishing job kept starting on schedule while doing nothing, for two days, with the error sitting in a log nobody reads. The acceptance checklist tests for this, but tokens will keep expiring after acceptance too.

3. A limit is reached. An overnight job that generates content hit a monthly spending limit on the account it ran on. It produced its usual output, then ended with an error, and another job sharing that account would have hit the same wall. The code was fine; the account limit was not.

4. The source behaves differently than you assumed. While counting reviews for this site, my collector clicked a site’s “show more” button to load extra reviews. The site loaded some of them twice. The code ran without errors, and I published a review count that was too high before I caught it and corrected the page. Nothing had changed in my code; I had not known how the page behaved.

The first two are the common ones for any business automation. The third grows with every AI step you add. The fourth is why a fix sometimes takes investigation rather than a one-line change, and why the rate matters.

The six lines to agree

Line 1 decides who pays: fix or change?

Fix

Does what the brief says again

• Something outside it changed: a login, a connected app, a limit
• Covered by the maintenance terms

Change

Does something new

• Includes you changing your own process
• A new order, budgeted as one

On Fiverr, put these in your messages with the seller before you order, and ask them to confirm there. That thread is the record you will point to later.

A message you can copy

Paste this into your messages with the seller before ordering, with your own numbers:

Before I order, can we agree how fixes work after delivery?

1. A fix = it stops doing what the brief says because something outside it changed. New behaviour = a new order.
2. First 30 days after acceptance: fixes included.
3. After that: [per-incident rate] per fix, or [monthly amount] per month for up to [N] fixes, cancellable by either side with two weeks’ notice.
4. Reply within [one working day] to a failure report; fix in place within [three working days] unless we agree otherwise.
5. Access stays on my accounts; I can remove it at any time.
6. At delivery: the workflow export or repository, and a one-page run-book.

Does that work for you, or what would you change?

Most sellers will change one or two numbers, and that is the point. The conversation happens now, while nothing is broken.

The copyable message, as a timeline

Illustration: the example terms from the message. Most sellers will change one or two numbers.

1. DeliveryYou get the workflow export or repository and a one-page run-book.
2. First 30 daysFixes included after acceptance.
3. After thatA per-incident rate, or a monthly amount for up to N fixes.
4. Either side can stopWith two weeks' notice. Access stays on your accounts.

When something fails

You report it→Reply within one working day→Fix within three working days

What the seller should hand you so fixes stay small

Maintenance is cheaper when the problem is found early and explained clearly. Three things make that happen:

• An alert that reaches you, not the seller, when a run fails, and also when it runs late or produces nothing, because those failures never show up as an error. You own the problem; you should be the first to know.
• A log you can read, with a line per run: started, what it did, finished or failed. When you report a failure, send the log line. It turns a vague “it stopped” into a ten-minute fix.
• A note of what each credential is for, and when it expires if it has an expiry. Most breakages are predictable from this list.

Keep the alert, the log and the dates on your side

A failed run

Run fails→Alert reaches you, not the seller→You send the log line→Ten-minute fix

An expiring credential

Note of what each credential is for→Expiry date in your calendar on acceptance day→A breakage you see coming

Where it goes wrong anyway

• The seller disappears. It happens, even with good sellers. The hand-over line is what saves you: with the run-book and the export on your side, any other seller can pick it up.
• Every fix becomes a change. If the seller starts calling fixes new work, go back to line 1 and the brief. This is why the brief should state the result in measurable terms.
• You change the process and expect the automation to follow. That is a change, not a fix. Budget for it as a small new order.

Wrap-up

Build price is what you compare between sellers. Maintenance is what you live with. Agree the six lines in the first conversation, keep the alert and the log on your side, and treat expiry dates as appointments. Then a breakage in month two is a short message and a small invoice, not a new project.