Pricing and engagement guide

AI consulting pricing starts with defined work

BaristaLabs prices a workflow after it understands the systems, risk, review path, and artifact the buyer needs. This page explains the engagement stages and cost drivers. It is not a universal quote.

Engagement stages

Each stage should end with a decision

Not every workflow needs every stage. The useful sequence is the one that resolves enough uncertainty to make the next decision honestly.

20-minute assessment

Purpose: Decide whether one workflow deserves a deeper review and identify the next useful step.
Inputs: A plain-language workflow note naming the systems, owner, bottleneck or risk, and decision you need.
Outputs: A fit and rough-scope conversation, with the most useful next step identified.
Decision: Leave the workflow manual, prepare missing information, use an existing tool, run discovery, or scope implementation.
Out of scope: A universal quote, technical design, production access, or a promise to implement.

48-hour discovery, when useful

Purpose: Turn an uncertain workflow into a bounded recommendation before anyone commits to a build.
Inputs: The workflow owner, representative examples, known systems and data boundaries, and available reviewers.
Outputs: A workflow and boundary map, risks and assumptions, a first artifact or pilot recommendation, and rough implementation scope.
Decision: Proceed to a scoped pilot or sprint, narrow the workflow, prepare data or access, choose another path, or stop.
Out of scope: Discovery does not automatically include a working integration, production deployment, or ongoing support.

Scoped pilot or implementation sprint

Purpose: Build and evaluate the smallest useful version of an agreed workflow boundary. BaristaLabs publishes a 3–6-week target for suitable scoped pilot deployments; it is not a blanket timeline promise.
Inputs: Approved scope, dependencies, access plan, representative test cases, reviewers, and acceptance evidence.
Outputs: The named implementation artifacts, evaluation evidence, known limits, deployment or test notes, and agreed handoff materials.
Decision: Accept the defined work, revise through an approved change, expand later, keep a human-led path, or stop.
Out of scope: Unlisted integrations, source cleanup, feature expansion, production operation, training, and support unless the quote includes them.

Optional ongoing support

Purpose: Keep an implemented workflow reviewed, documented, and maintained when the operating model needs continued help.
Inputs: A live or accepted workflow, named owners, monitoring or review needs, and an agreed support boundary.
Outputs: Only the monitoring, tuning, maintenance, documentation updates, response path, or feature work stated in the support agreement.
Decision: Continue, change, transfer, narrow, or end the support lane under its agreed terms.
Out of scope: Support is not implied by the initial build and does not include unspecified response times, availability, or new features.

Scope drivers

What changes an estimate

A useful estimate explains which assumptions carry the most uncertainty instead of hiding them inside one total.

Systems and integrations

The number of systems matters less than the depth of each connection: fields, permissions, undocumented rules, exceptions, and ownership all affect the work.

Data preparation and sensitivity

Source quality, cleanup, classification, retention, client records, financial data, and credentials change the access plan and review required.

Action risk

Drafting is different from sending, publishing, changing a record, affecting money, or changing access. Higher-risk actions need stronger approval, receipt, and rollback paths.

Review and evaluation

Representative cases, difficult cases, unacceptable failures, source evidence, reviewer availability, and sign-off requirements determine what acceptance takes.

Deployment environment

A contained prototype, client-owned cloud account, on-premise system, production integration, or regulated environment creates different setup and operational work.

Documentation and handoff

Repository access, deployment notes, configuration inventory, test cases, administrator guidance, known limits, and training must be named rather than assumed.

Support needs

Monitoring, incident response, model or source updates, integration maintenance, office hours, and feature changes require a separate, explicit boundary.

One-time work

Separate the build from operation

A project estimate covers only the defined consulting and implementation work. It should name which preparation, deployment, documentation, and handoff activities are part of that boundary.

Workflow and boundary definition
Data or integration preparation that the quote names
Implementation and configuration
Evaluation against agreed cases
Deployment, documentation, and handoff that the quote names

Recurring and provider costs

Mark every ongoing item explicitly

Each quote should mark expected costs as included, excluded, client-paid, estimated, or unknown. When known, it should also identify the provider, charging unit, and billing account owner.

Model and API use

Provider and usage charges can continue after launch.

Hosting

Compute, deployment, and network services.

Software licenses

Automation platforms, seats, connectors, or other third-party tools.

Monitoring

Logs, alerts, evaluation services, and operational review.

Storage

Files, databases, backups, and retention.

Support

Maintenance, tuning, incident response, and future changes when contracted.

Commercial controls

Make “done,” change, and exit inspectable

Fixed scope

The quote should name the workflow, deliverables, dependencies, exclusions, and evidence that marks the agreed work complete.

Approved changes

New information does not silently expand the engagement. A change should state the effect on scope, timing, and cost before an authorized person approves it.

Acceptance evidence

The parties agree on test cases, required behavior, unacceptable failures, the reviewer, and the record used to accept or revise the work.

Ownership and handoff

The quote or agreement should say who owns code, prompts, configurations, documentation, accounts, and project artifacts, plus exactly what the client receives.

Access removal

Handoff includes the path for transferring client-owned accounts, exporting client material, removing vendor access, and recording any retained dependencies.

Before an estimate

Resolve the biggest unknown first

Score one workflowCheck impact, effort, risk, ownership, and the next useful step.Compare implementation pathsDecide whether the work fits a tool, internal build, contractor, review, or implementation partner.Review the data boundaryName sensitive fields, permissions, retention, approval, access removal, and rollback before sharing access.Inspect relevant proofKeep client-approved case-study evidence separate from the delivery method and your own estimate.

FAQ

Pricing questions to settle before approval

How does pricing work?

BaristaLabs prefers fixed-scope work tied to a defined workflow or artifact. The estimate follows a fit and rough-scope review, then states the included work, exclusions, assumptions, acceptance evidence, and cost responsibilities. This page explains that structure; it is not a universal quote.

Is discovery paid?

The right discovery path depends on how much uncertainty must be resolved and what artifact the buyer needs. A scoped estimate will state whether discovery is a separate paid engagement, part of another engagement, or unnecessary. The 48-hour label alone does not determine price.

What can change the estimate?

Systems and integration depth, source-data preparation, data sensitivity, action risk, evaluation and review needs, deployment environment, documentation and handoff, stakeholder availability, and support requirements can all change the scope. Approved changes should be recorded before added work begins.

Which costs continue after launch?

Model or API use, hosting, software licenses, monitoring, storage, security services, and support may continue after launch. Each quote should mark every expected item as included, excluded, client-paid, estimated, or unknown and name the account owner when known.

What does the client own?

Ownership depends on the scoped agreement. Before approval, the quote or agreement should identify ownership and access for code, prompts, workflow configuration, documentation, cloud and model accounts, domains, credentials, test cases, and other project artifacts, plus the handoff and access-removal steps.

Request the next useful scope

Bring the workflow shape, not a polished specification

Name the workflow, systems, action risk, current owner, and the decision the estimate must support. Do not include sensitive data or credentials in the public form.

Request a scoped estimate