Start with one workflow. Know what comes next.

We describe the workflow, intended result, connected systems, inclusions, exclusions and acceptance tests in the engagement. If new complexity appears, we review the options together: keep the scope, exchange work, defer, stop or agree a priced and scheduled change.

What we agree together: Scope before implementation, and any change before it is taken on.

We identify the people who know the workflow, useful examples, access assistance, reviews and decision points. The time required depends on the actual work. If a dependency slips, we review the plan together rather than assuming a fixed delivery window.

What we agree together: Participation and decision points for each agreed stage.

We map what information is needed and where it may flow: inputs, the application, suppliers, outputs, logs, backups and deletion. Together we set the permitted uses, access, location, isolation, encryption, owners and incident route. We can start with synthetic or redacted examples where appropriate.

What we agree together: The data and access boundary before sensitive information or access is shared.

The answer depends on the selected product, endpoint, model, region, account settings and current terms. Training, monitoring, logs, backups and retention are separate questions. We review evidence for the specific route and any fallback; no universal zero-retention or no-training promise is made.

What we agree together: The provider and data route before that route is authorised.

Client-controlled, vendor-managed and hybrid arrangements are possible. We start with your existing systems where practical, then agree the environment, account and billing owners, permissions, monitoring, recovery and exit responsibilities for the selected design.

What we agree together: Hosting and operating responsibilities during design, before deployment.

We distinguish your data and inputs, commissioned deliverables, reusable components and third-party software. The agreement identifies the source, configuration, documentation, licences and transfer rights that apply. A public demo does not determine ownership of a commissioned system.

What we agree together: Deliverables and rights in the implementation agreement.

We consider hosting, storage, licences, model usage, retries, exceptions, support and taxes at expected and peak volumes. A starting workflow measure and quality checks help assess results. Time released is not automatically cash saved, and a synthetic demo is not a measured client return.

What we agree together: Cost assumptions, limits and evaluation measures before approving the build.

We identify who owns each account and subscription, how charges are paid, how usage is seen, and who may approve overages or renewals. The arrangement also needs a clear path if a supplier pauses service or the engagement ends.

What we agree together: Billing ownership and spending limits before a paid integration or service begins.

We design for invalid or uncertain inputs and unavailable services rather than displaying invented success. Validation, human review, safe retries, duplicate handling, monitoring, fallback and rollback are chosen for the workflow. Material provider or input changes may need fresh testing and approval.

What we agree together: Failure handling and acceptance tests before live operation.

We set out the covered systems and work, service hours, contact route, response expectations, responsibilities and supplier dependencies. Ongoing support is agreed separately where useful; it does not imply around-the-clock cover or a guaranteed fix time.

What we agree together: Support terms before production use or an ongoing partnership.

We shape the handover around the person who will operate the workflow. It can cover the system and data flow, source and configuration where applicable, user guidance, exception steps, acceptance evidence, access transfer, exports, recovery and support contacts.

What we agree together: Handover contents before implementation, then the delivered package at handover.

If a settling-in period is part of the engagement, we define its start and end, the time or hours covered, what counts as a defect rather than new work, and who takes over afterward. The arrangement is specific to the agreed work, not a universal fixed period.

What we agree together: Any post-launch period and owner before go-live.

For a Founder-led service, continuity comes from accessible documentation, licensed and portable source or configuration where agreed, fallback steps, access custody and recovery planning. A substitute maintainer or emergency cover would need an explicit arrangement, not an assumed second engineer.

What we agree together: Continuity and recovery arrangements before production reliance.

We identify the available exports, source and configuration transfer, documentation, access revocation, billing handover, assistance and data-retention limits. Supplier licences or architecture can affect portability, so we surface those constraints while choosing the solution.

What we agree together: The exit route before implementation, and the actual transfer steps when needed.