Should Automation Maintenance Be Priced Separately From the Build?

Should automation maintenance be priced separately from the build?

Yes. I think the build and the maintenance are different jobs with different risks, and bundling them hides the second one. A fixed fee for the build covers getting the system working. Maintenance covers keeping it working while vendors, data, and the business keep changing underneath it.

This is one of the conversations I find most useful to have early with a client, and one of the easiest to skip. Everyone is excited about the build. Nobody wants to talk about month seven, when a field gets renamed in the CRM and the lead routing quietly sends every new lead to the wrong owner.

So this is my honest view on why the two should be separate, what maintenance actually covers, and how to scope it so neither side feels trapped. I work on fixed-fee projects, most between $1,000 and $10,000, and that structure shapes how I think about all of this.

Why is an automation never finished on launch day?

Because every automation depends on systems that keep changing. The CRM gets new fields, the form gets a new question, a vendor retires an API version, and the team changes how they work. The automation that was correct at launch slowly drifts out of date, even if nobody touches it.

Vendor changes alone make this clear. On September 15, 2026, HubSpot announced the end of support for its v1 to v3 APIs and legacy apps, with a September 2027 enforcement date. Any automation built on those endpoints, however well it was built, now has a deadline it did not have when it launched.

Then there are the human changes, which are harder to predict. A new sales hire wants leads routed differently. Marketing adds a new lead source. Someone edits a property in the CRM without knowing three workflows depend on it. None of that is a defect in the build. It is the normal life of a system inside a business that is growing.

What goes wrong when maintenance is bundled into the build price?

The client assumes the system will run forever without attention, and the builder either absorbs unpaid fixes or has an awkward conversation later. Both outcomes damage trust. Bundling makes the price look simpler at the start, but it pushes a real cost into the future where nobody planned for it.

From the client side, a single price reads as done. When something breaks a few months later, they reasonably ask why they are paying again for something they already bought. That frustration is fair if nobody explained the difference between building and maintaining.

From the builder side, bundling creates a quiet incentive to over-engineer or to avoid follow-up work. Neither helps the client. I would rather name the two jobs clearly at the start, so the client knows exactly what the fixed fee covers and what happens after launch.

What should automation maintenance actually cover?

Maintenance should cover monitoring, fixing breakages caused by outside changes, small adjustments as the business evolves, and keeping documentation current. It should not quietly absorb new features. A clear line between keeping the system working and making it do something new protects both sides.

Monitoring is the base layer. Someone should notice when runs fail, when error rates jump, or when expected records stop arriving. Fixes for outside changes come next: a vendor API update, a renamed field, a form that changed its structure. Those are the core of maintenance because they are not caused by anyone's mistake.

Documentation is the part people forget. Every fix changes the system slightly. If the change log and the handover notes are not updated, the next person to touch the automation starts from an inaccurate picture. I treat keeping those current as part of the job, and I covered the practice in how to keep a change log for client automations.

Where is the line between maintenance and new work?

If the change keeps the system doing what it was designed to do, it is maintenance. If the change makes it do something it was never designed to do, it is new work. That single test settles most disagreements before they start, and it is worth writing into the agreement in plain words.

Some examples make the line concrete. A vendor changes an API and the sync breaks: maintenance. A new sales rep joins and needs to be added to round-robin routing: usually maintenance, since the routing logic already exists. The client wants to add lead scoring that did not exist before: new work, scoped and priced on its own.

The gray areas are real, and I would rather discuss them openly than pretend they do not exist. When a request sits in between, a short conversation about whether it changes the design or just the settings usually resolves it. What matters is that both sides agreed on the test before the first gray request arrived.

How do you scope maintenance honestly?

Scope it by the size and fragility of the system, not by a guess at how many hours things will take. Count the workflows, the external systems involved, and how often those systems change. A small automation touching two stable tools needs far less attention than a large one spanning six fast-moving ones.

I find it helps to describe maintenance in terms the client can check. What gets monitored, how quickly issues get looked at, what counts as included, and what triggers a separate quote. Specific commitments like those are easier to trust than a vague promise of ongoing support.

It also helps to be honest that maintenance is optional. Some clients have an internal person who can own the system after handover, and for them a clean handover plus documentation is the right answer. Others have no one technical, and for them ongoing maintenance is the difference between a working system and a slow failure. Both are legitimate choices.

How does this fit with fixed-fee pricing?

Fixed-fee pricing works well for the build because the scope is defined. Maintenance has a different shape, because the work depends on changes nobody can fully predict. Keeping them separate lets the build stay a clear fixed price while maintenance gets its own honest structure.

I like fixed fees because the client knows the cost up front and I carry the risk of my own estimate. That is fair for a build with a clear scope. It would not be fair to stretch that same fixed fee over an open-ended future where a vendor might change something important next month.

Separating the two keeps the build price honest. It is not padded to cover imagined future fixes, and the client does not pay for maintenance they may never need. I wrote more about how I think about project pricing in general in why most of my projects land between $1,000 and $10,000.

What should a client ask before agreeing to maintenance?

Ask what is monitored, how issues are reported and fixed, what counts as included, and how you can leave. A good maintenance arrangement is easy to understand and easy to end. If the builder cannot explain the exit, or if the documentation lives only in their head, that is a warning sign.

The exit question matters most. A client should always be able to take the system elsewhere, with current documentation, access to every account, and a clear map of what depends on what. Maintenance should exist because it is useful, not because the client is locked in.

I would also ask how the builder learns about vendor changes. Someone who reads vendor changelogs and plans migrations before deadlines is offering real protection. Someone who waits for things to break is offering a repair service, which is useful, but different.

What have I learned from running automations in production?

That the systems which last are the ones someone keeps an eye on. I have automations in production for Ajust, built on Airtable and WhaleSync, and for Kismet Health, built on HubSpot via Zapier. Systems like these keep serving people only when someone owns their health after launch.

The Ajust automations have supported more than 25,000 cases delivered, more than 400,000 people helped, and more than 50,000 hours saved. Numbers like that are why I take the maintenance question seriously. When an automation sits in the middle of real work for real people, a quiet failure is not a minor inconvenience.

The broader lesson I keep returning to is that maintenance is a design decision, not an afterthought. Who owns the system after launch should be decided before the build starts, because it shapes how the system should be built, documented, and handed over.

What should you do next?

If you have automations running today, decide who owns their health after launch and write it down. If you are about to commission a build, ask the builder to price maintenance separately and explain the line between maintenance and new work before you sign.

Either way, make sure the documentation and account access sit with your team, not only with the builder. That one step keeps every option open, including maintaining it yourself.

I build websites and the automations behind them for lead generation, and I think maintenance belongs in the first conversation. If you want an honest view on what your system will need after launch, reach out and let's chat.