What business result will the first build deliver?
Ask for one observable outcome, such as preparing a daily follow-up list or turning approved intake into a reviewable draft. Avoid a scope defined only as “an AI employee” or a collection of tools. The proposal should name the trigger, inputs, output, human reviewer, success measure, and work that remains outside the project.
Can you show a working proof?
A demonstration should use a realistic test case and show the full path from input to verified result. Ask what happens when required data is missing, a website changes, or an account connection fails. A polished chat response is not proof that the workflow can operate safely.
Which information stays local, and which leaves?
Request a data-flow map listing each model, storage location, connected service, and remote-support path. Ask what each provider retains and how access is revoked. “Private” and “local” should translate into specific, testable handling rules. The privacy buyer checklist covers the details.
Who owns the system and its records?
Clarify ownership of source code, workflow definitions, prompts, documentation, data, logs, and generated assets. Identify any subscriptions or developer-controlled accounts required to keep operating. The business should receive useful exports and a clear process for ending support without losing its work.
How are permissions and approvals enforced?
Ask which accounts the assistant uses, whether access is read-only where possible, and which actions always require confirmation. Sending, publishing, purchasing, deleting, and changing live settings deserve explicit treatment. Controls should exist in the implementation, not only in a verbal promise.
What affects the price?
Cost depends on the number of workflows, data cleanup, integrations, custom interfaces, security requirements, model usage, testing, documentation, training, and ongoing support. Ask for assumptions and exclusions. Separate the one-time build from hardware, software subscriptions, model usage, maintenance, and future changes.
How will maintenance and failures work?
Websites, APIs, and software change. The agreement should say who monitors failures, how quickly important problems are surfaced, what support includes, and how updates are tested. Ask for a manual fallback and a recovery plan. Critical workflows need clear ownership after launch.
What documentation and handoff are included?
Expect an inventory of components, data sources, permissions, recurring jobs, backup locations, approval gates, and recovery steps. The owner should know how to pause the system, review its activity, restore a backup, and revoke support access. Training should cover normal use and abnormal conditions.
How will acceptance be verified?
Define tests before the build begins. Include a normal case, missing-data case, permission denial, provider outage, restart, backup restore, and export or deletion request where relevant. Final payment or launch should depend on the agreed tests, not simply the passage of time.
Start small enough to learn
A bounded first workflow reveals data quality, approval needs, and maintenance cost without locking the business into a large system. Once it performs reliably, expand using the same ownership and verification standards. See where local AI fits in a small business for candidate workflows or bring one repeated process for an initial scope.