Engagement models and investment
Automiq scopes assessments, bounded builds, embedded delivery, and continuing support around the business outcome, current system, uncertainty, risk, and ownership required after launch.
Four ways to engage
The engagement can change as evidence improves. A paid assessment is not mandatory for every small, well-defined request, and a continuing team should not be used to hide an undefined outcome.
Reduce uncertainty
A bounded review of a product, repository, workflow, pilot, data, integrations, risks, or migration. Outputs can include findings, decision options, architecture, evaluation plan, backlog, milestones, and evidence gaps.
Ship a defined outcome
Design and engineering for an accepted capability, product release, integration, automation, modernization step, or AI production gate with explicit assumptions and launch conditions.
Keep building
Continuing capacity around a roadmap, production AI capability, reliability program, integrations, or transition while responsibilities remain explicit between Automiq and the internal team.
Operate responsibly
Post-launch work for production findings, monitoring, incidents, dependencies, model or provider change, security maintenance, product learning, and approved roadmap growth.
Commercial decision
No model removes the need to define scope, customer inputs, change handling, ownership, and what happens when evidence changes the plan.
| Option | Best when | Main tradeoff |
|---|---|---|
| Fixed bounded milestone | Scope, assumptions, acceptance, dependencies, and exclusions are sufficiently stable. | New findings or changed priorities require explicit scope exchange or a new milestone. |
| Staged discovery then build | The direction is credible but repository, data, workflow, integration, AI, or risk evidence is not strong enough for a responsible build estimate. | The production investment and schedule remain a later decision, and assessment can recommend not building. |
| Dedicated delivery capacity | A live roadmap needs continuing cross-functional capacity with a strong internal product owner and explicit work boundaries. | Capacity must still be prioritized and governed; it is not a substitute for acceptance or product decisions. |
| Defined support model | The system is live and the support surface, service objectives, escalation, maintenance, and exclusions can be stated. | New product development and major changes require separate prioritization and commercial treatment. |
Investment drivers
Two pages with the same number of screens can have entirely different production responsibilities.
Unknown users, behavior, content, workflow, policy, acceptance, or commercial assumptions create research and iteration.
Identity, tenancy, permissions, history, migration, integrations, payments, jobs, events, reconciliation, and admin shape engineering.
Representative data, retrieval, evaluation, human review, security, regions, audit, providers, actions, fallback, and model change add production work.
Environments, stores, rollout, observability, reliability, support, documentation, transition, and continuing operation affect total investment.
Estimate process
The process scales with the work. A small integration needs less evidence than a multi-surface product or consequential AI workflow, but the logic stays visible.
Understand the problem, users, current system, desired outcome, constraints, owners, evidence, and whether custom engineering is justified.
Outcome: Recommended next route
Review the minimum workflow, repository, data, integration, product, security, AI, or operating evidence needed to estimate responsibly.
Outcome: Assumptions and uncertainty record
Define scope, acceptance, dependencies, customer inputs, non-goals, team shape, release conditions, ownership, and change handling.
Outcome: Reviewable commercial scope
Present investment, schedule, payment structure, exclusions, risks, third-party costs, and the next decision without a hidden low-cost package.
Outcome: Accepted, revised, or declined engagement
Included versus separate
The proposal should identify what Automiq delivers, what the customer supplies, what providers charge, and who owns the system after release.
Agreed discovery, design, engineering, tests, evaluation, environments, releases, documentation, training, and handover are stated per milestone.
Domain decisions, user access, content, data rights, internal systems, approvals, security policy, provider procurement, acceptance, adoption, and operational owners remain visible.
Cloud, models, platforms, data, communications, licenses, stores, payment services, monitoring, professional assurance, support, and future change are identified separately.
Questions, answered
Straight answers about estimates, fixed pricing, paid discovery, third-party costs, changes, and starting small.
Software and AI engagements vary materially by product uncertainty, users, workflows, interfaces, architecture, data, migration, integrations, AI evaluation, security, reliability, release obligations, support, and customer dependencies. A generic price would either hide assumptions or describe a different service.
A bounded milestone can be priced against explicit assumptions, acceptance, dependencies, change handling, and exclusions. Research, legacy remediation, evolving product delivery, or uncertain data and integration work may need a staged or capacity-based structure.
The initial 30-minute fit call is currently free. Substantive workflow mapping, repository audit, architecture, data review, AI evaluation, security analysis, or product definition may be a paid assessment because it creates reusable decision work.
A useful proposal states the business outcome, scope, non-goals, acceptance, assumptions, dependencies, customer responsibilities, team shape, milestones, payment structure, third-party costs, ownership, release, support, change handling, and material risks.
Cloud, models, platforms, messaging, data, payment providers, domains, app stores, licenses, devices, travel, taxes, professional review, certification, penetration testing, and continuing support remain separate unless explicitly included.
No. The previous low-cost small-business packages do not match the company’s current position as a software and AI engineering partner. This page replaces those offers with scoped production engagement models.
The agreement should define whether a change is a clarification, defect, exchanged scope, new milestone, or additional capacity. Impact on acceptance, schedule, dependencies, risk, and investment is reviewed before work expands.
Yes. The preferred first step is the smallest milestone that creates useful business or technical evidence while meeting the production responsibility of the use case.
Talk to the engineering team
Bring the business outcome, current system, users, evidence, risks, constraints, dependencies, and intended ownership. Automiq will identify the evidence required for a responsible estimate.