What to ask before your first AI project.

Start with the result you need

An AI engagement might be advice, a tool selection, a working prototype, or a production system. Decide which result you are buying. For a first build, look for a specific task, authorized inputs, an output someone can check, and a test that will show whether the tool is useful.

Jotbolt focuses on bounded first builds for small businesses. This is the checklist I would want a prospective client to use when considering my work.

What a first-build engagement should cover

1. The current workflow. Who does the task, how often it happens, where errors occur, and whether an existing tool could solve it. The opportunity finder can help organize that discussion.
2. A written scope. Supported inputs, outputs, integrations, exclusions, and the point where a person reviews or takes over. The quote-drafting example and equipment-manual example show possible boundaries.
3. A clear price and change process. Fixed fees work well when the boundaries are clear. If discovery is required first, agree on its cost and deliverables separately. Define how changes affect the price and plan.
4. A knowledgeable reviewer. The person who does the task should check examples and exceptions. Agree on their availability and responsibilities.
5. An acceptance test. Use representative past examples, known answers, and failure cases. Define the accuracy, time, or handling criteria before the build.
6. A handoff and operating plan. Document access, limitations, running costs, maintenance, and support arrangements.

How to compare the cost

A generic hourly rate does not tell you what a project will cost or whether it will help. Compare proposals for the same outcome and make sure discovery, integrations, testing, handoff, and ongoing charges are visible.

Jotbolt quotes a first build after agreeing on the task and its constraints. The project approach explains what goes into that scope. There is no published standard price or delivery time.

The cost calculator can estimate the value of time spent on a task. Check ongoing software costs, remaining review work, adoption, and what the team would do with the time gained. Time released is not automatically cash saved.

Questions to ask on the first call

• What will exist when we finish? Ask for specific outputs and a demonstration of the intended workflow.
• Who needs to participate? Identify the workflow owner, approver, and anyone responsible for data or systems.
• What happens when information is missing or wrong? Look for an explicit exception and human-review path.
• Where will the data go? Agree on the service, account, permissions, retention, and processing terms before sharing project data.
• How will we test it? Ask to include known answers and examples the tool should decline.
• What is included in the price? Separate project work from subscriptions, hosting, model usage, and support.
• What do we receive and maintain? Agree on rights to custom work, access, documentation, and third-party license restrictions.
• What evidence supports the proposal? Distinguish a worked demonstration from a customer result. Jotbolt's public examples use fictional data.

When a small first build makes sense

Look for repeated work with inputs you can provide, an output a person can inspect, and enough volume to justify the change. Examples include preparing a parts worksheet, finding an approved manual passage, or checking whether paperwork is complete.

A custom build may be premature if the process is changing constantly, the input data is unavailable, no one can review the results, or an existing product already meets the need. Decisions such as pricing, credit, hiring, and safety need an appropriate accountable person; preparing information is a different task from making the decision.

Working locally or remotely

Jotbolt is based in Nashua, New Hampshire, with on-site working sessions available within about 90 minutes and remote work by video. See the local service area and Nathan's operating background.