What would you like to automate?

Yes. A new-lead notification is one possible starting point. More connections can be added later.

We check available APIs, permissions and system limits before agreeing the work.

We agree this in advance for publishing, uncertain data or consequential actions. Exceptions go to the responsible person.

No, not every project needs one. A separate review makes sense when an important question is still unanswered and should end with a clear finding or next step; a pilot tests a limited version of a solution, and neither means a full system is ready. What a paid stage covers and what it costs need to be agreed first.

We can discuss the change before adding it: it may affect the work, access, checks, price or dates—even if it looks like a small button. An extra feature is different from fixing something that fails the agreed requirements. The agreed terms need to make that distinction clear; neither an extra charge nor unlimited free changes should be assumed.

That should be settled before work starts: someone needs to own content updates, access and the response to problems. Handover, regular maintenance, incident support and new features are different responsibilities. Any support period, response time and cost need to be written down; ongoing support is not automatically part of the initial build.