Pricing
How we charge.
ASCENTI prices discovery to the size of the question and agrees it before any work begins. What follows is priced once we know what it should be, and that varies: advice, a process change, training, a prototype or a production build are different pieces of work with different economics. What stays constant is that you agree a number for a defined piece of work before it starts.
How the money works
Two commitments, in order, and an optional third. Not a package ladder.
01 · Discovery, priced to the question
We agree what discovery will cover and what it will cost before it starts. A single process in a small business is a smaller number than an operation spanning several teams, and we would rather scope it honestly than quote a package length. It is deliberately sized to be a decision rather than a project.
02 · The next step, priced once we know what it is
Discovery ends in a recommendation, and the recommendation is priced as its own defined piece of work. Where that is a build, it is quoted as a fixed scope against an agreed specification with staged payments against milestones you can see working. Where it is advice, a process change or training, it is a smaller and shorter commitment, and we say so.
03 · Running it, monthly
A live system needs hosting, model usage, its third-party subscriptions and someone keeping it healthy. Many clients wrap all of that into one monthly agreement with us rather than administering it themselves. Some take the handover and run it in-house instead, and the documentation is the same either way.
Why we price defined work rather than hours
Open-ended hourly billing puts the client and the consultancy on opposite sides of every estimate. It rewards the supplier for the work taking longer and punishes them for solving the problem quickly, which is precisely backwards.
Pricing a defined piece of work moves the delivery risk onto us, which is where it belongs. We are the ones who can estimate it, and if we get it wrong that is our judgement rather than your invoice. It also forces the scoping conversation to be honest, because a vague scope becomes our problem rather than a future variation.
The trade-off, stated plainly
A fixed scope means the scope is fixed. Adding something mid-build goes through a change process with its own price, and we will not pretend otherwise to win the work. That is the deal, and it is a better one than an estimate that quietly doubles.
What actually drives the cost of a build
If you are trying to form a rough expectation before speaking to anyone, these are the factors that move a quote most, roughly in order of impact.
Number of systems touched
- Cheaper when
- One or two, with modern APIs
- More expensive when
- Several, including legacy or heavily customised platforms
Integration quality
- Cheaper when
- Documented, supported APIs
- More expensive when
- No API, or a vendor that charges for access
Process complexity
- Cheaper when
- One path with a handful of exceptions
- More expensive when
- Many branches, or rules that live only in people's heads
Consequence of error
- Cheaper when
- Recoverable, a rework
- More expensive when
- Regulatory, financial or customer-facing, needing heavier controls
Data readiness
- Cheaper when
- Reachable and reasonably consistent
- More expensive when
- Scattered, duplicated or locked in documents nobody has structured
Change appetite
- Cheaper when
- Willing to simplify the process first
- More expensive when
- The existing process must be reproduced exactly, quirks included
| Factor | Cheaper when | More expensive when |
|---|---|---|
| Number of systems touched | One or two, with modern APIs | Several, including legacy or heavily customised platforms |
| Integration quality | Documented, supported APIs | No API, or a vendor that charges for access |
| Process complexity | One path with a handful of exceptions | Many branches, or rules that live only in people's heads |
| Consequence of error | Recoverable, a rework | Regulatory, financial or customer-facing, needing heavier controls |
| Data readiness | Reachable and reasonably consistent | Scattered, duplicated or locked in documents nobody has structured |
| Change appetite | Willing to simplify the process first | The existing process must be reproduced exactly, quirks included |
The last row is the one clients have the most control over and rarely think about. Insisting an automation reproduce every quirk of a process that grew by accident is often the single largest cost driver in a build.
Ongoing running costs
A production AI system costs something to keep running, and those costs should be sized before you commit rather than discovered afterwards.
- Model usage, which scales with volume, and we size the per-run cost during design
- Hosting and infrastructure
- Any third-party subscriptions the workflow depends on
- Support, and the work of keeping the thing healthy as your systems change
Commonly these are wrapped into one monthly agreement with us rather than left as four separate line items for you to administer. That is a convenience and a service, and it is worth being clear about what it is not: it is never the price of continuing to use a system you already own.
We design workflows so expensive reasoning only happens at the steps that need it, which is usually the difference between a running cost that is a rounding error and one that becomes a conversation.
What we do not do
- We do not resell platforms or take vendor commissions
- We do not charge a licence for software you paid us to build
- We do not make an ongoing agreement the price of keeping access to your own system
- We do not run open-ended hourly engagements
- We do not hold your system hostage: the source and the environment are yours
- We do not quote a build before discovery, because the number would be fiction
- We do not recommend a build when the problem does not call for one
Frequently asked questions
How much does AI consulting cost in Australia?
It varies enormously with scope, so any single number quoted without a conversation is marketing. What we can be specific about is the structure: discovery is scoped and priced to the size of the question and agreed before it starts, and whatever follows is priced as its own defined piece of work once we know what it should be. You get a real number before each commitment rather than an indicative range.
Why won't you publish a price list?
Because the work is not a product with tiers. Understanding one process at a twenty-person business and understanding an operation spanning four systems and three teams differ by an order of magnitude, and so do the things we might recommend afterwards. A published number would be either misleadingly low or unhelpfully high. Discovery exists precisely so the next number is real rather than indicative.
Do you charge for the first conversation?
No. The first conversation is thirty minutes about a process that frustrates you, and it costs nothing. If the honest answer is that there is nothing worth doing, that is a shorter conversation and it still costs nothing.
What if a build goes over scope?
That is our risk rather than your invoice. A fixed scope means a fixed price against the agreed specification. If you want something added mid-build it goes through a change process with its own price, agreed before it is done.
Do you require a long-term contract?
Discovery is a defined piece of work and whatever follows is another one. Where a system needs running afterwards, that is a monthly arrangement rather than a multi-year commitment. Your data and the business knowledge behind the process stay yours throughout, and the commercial terms for a given build are set out in writing before it starts rather than left to be discovered later.
More questions answered on the full FAQ.
Read next
Get a real number.
Thirty minutes on the process you'd point this at, and we'll scope what understanding it properly would take, with the number agreed before anything starts.