Home/How pricing works
HOW ENGAGEMENTS ARE PRICED

AI automation pricing: fixed scope, fixed price, a pilot first.

Aldenebai prices its work in three steps: a free Automation Audit that ranks what to automate, a fixed-scope, fixed-price pilot on a slice of real traffic with a named target, then the full system at a price agreed before it is built. There is no price list, because the same system costs very different amounts depending on your integrations and volumes. This page explains what drives the number, what is always included, and what it costs to run. Websites, apps, and internal systems skip the pilot: one call, one fixed-price proposal, one launch. How a build is priced ↓

Step 1 free audit and written Automation Map Step 2 fixed-price pilot, named target Step 3 full system, price agreed up front
Start with the free audit → You leave with the map and a realistic estimate, whether or not you continue
WHAT DRIVES THE PRICE

Why two support agents cost different amounts

The system is the same shape every time: intake, decision, action, escalation, audit trail. What changes is what it has to connect to and how much can go wrong.

A support agent for a team with one helpdesk and good documentation is a compact build. The same agent that also has to read billing, touch three legacy systems, and follow a regulated escalation policy is not. The audit makes those differences explicit before anyone talks about money.

Integrations. How many systems the machine reads from and writes to, and whether they have APIs.
Volume and variety. How many cases a day, and how many kinds of case.
Risk. Which actions are irreversible and need a human gate, and how strict the audit trail must be.
Knowledge. Whether the answers exist in writing, or documentation has to be built first.
Existing tests and CI. A codebase with pipelines is faster to automate than one without.
THE THREE STEPS

From a free call to a running system, with a price at every step

01

The Automation Audit: free

Thirty minutes. You leave with a written map: every repetitive job ranked by return and risk, a realistic estimate for the first system, and the honest "not yet" where a machine would underperform. Book it →

02

The pilot: fixed scope, fixed price

The first system on a slice of real traffic, with a named target agreed in writing, for example a resolution rate on the top five ticket types or a turnaround time on one repository. It goes live early and proves the number on your data.

03

The full system: price agreed before the build

What it does, what it deliberately does not do, guardrails, tests, timeline, price. The price does not move unless you change the scope. Delivered into your repositories and accounts, with documentation, so your team owns it.

THE PILOT, SCOPED

Small enough to prove, real enough to count

The pilot is not a prototype. It is the system, its monitoring, and its tests together, on a slice of real work, with a target written down before it starts. For reference, the client's support agent took about a month from kickoff to its first live ticket.

SCOPE
One slice of real traffic: for example the top five ticket types, one repository, or one report.
INCLUDES
The system, its monitoring and alerts, its automated tests, its guardrails, and the kill switch.
IF THE TARGET IS MISSED
You stop. The pilot is a fixed price agreed before it starts, so the most a miss can cost you is that one price, and you keep the system, its tests, its runbook, and the measurements that showed it missed. Widening the slice is a separate decision with its own price; nothing rolls forward automatically.
TARGET
Named in writing before the build: a resolution rate, a turnaround time, hours removed.
TIMELINE
Set in the proposal for your case, and scoped small enough to show a live result quickly rather than after a long build.
THEN
Widen the slice, or stop. Either way you keep what was built.
AFTER GO-LIVE

Who runs it at 3am: your team, or Aldenebai

Every system ships ready for your team to run. Whether Aldenebai keeps running it is a choice made per system, at proposal time, and it can change later.

HANDOVER
Your team runs it. Runbook, dashboards, alerts wired into your channel, a defect warranty after go-live, and the kill switch. Aldenebai stays available at fixed scope for changes.
OPERATE
Aldenebai runs it. Monitoring, threshold tuning, model and prompt updates, and a named response time, for a monthly fee agreed in the proposal. Cancel monthly; the system and its runbook stay yours.
EITHER WAY
Switched off, the work routes back to your team exactly as it did before. Nothing depends on Aldenebai being reachable.
ALWAYS INCLUDED

What every price covers

These are not add-ons. A system without them is a demo, and Aldenebai does not ship prototypes.

GUARDRAILS
Confidence thresholds, allowed-action lists, and a human gate on anything irreversible.
TESTS
Automated coverage of the system's own behaviour, run before every change.
AUDIT TRAIL
Every decision logged with its reason, reviewable at any time.
KILL SWITCH
Stop the system instantly, whatever it is doing.
DOCUMENTATION
Enough that any competent engineer can run or extend the system without Aldenebai.
DATA & SECURITY
Model calls run through your own AWS account (Bedrock): your data is not used to train provider models, Aldenebai holds no keys, and content and audit trails stay in your systems.
OWNERSHIP
Yours. Your repositories, your accounts, your infrastructure. No licence, no per-seat fee.
RUNNING COSTS

What it costs after it is live

Systems run on your own accounts, so the running cost is model usage and infrastructure you can see on your own bills. Cheaper models handle routine reading and routing; the capable model is used only where the decision needs it. A hard monthly ceiling is set in the design so the bill can never surprise you.

There is no Aldenebai licence and no per-seat charge. Changes and new systems are scoped and priced when you want them.

Want a price for your case?
The audit produces it, in writing, in 30 minutes. Free, and yours to keep either way.
Book the Automation Audit →
BUILDS, NOT SYSTEMS

How a website, app, or internal system is priced

A build has no pilot to run, so the shape is shorter: one call, one fixed-price proposal, one launch.

STEP 1
The same free 30-minute call, pointed at the brief: what the site or app must do, what your team must be able to change without a developer, and what repeats around it.
STEP 2
A fixed-scope, fixed-price proposal: the pages and flows, the admin portal and its roles, the integrations, the test suite, the stack, and the launch date. The price moves only if you change the scope, in writing.
STEP 3
Built in stages, so a working version is live and testable well before the whole scope is. Automated tests run on every change from the first sprint.
WHAT MOVES THE PRICE
Integrations, payments, the number of roles and flows in the admin, and how much content your team must be able to edit itself.
AFTER LAUNCH
Handover with documentation, tests, and a walkthrough, on your accounts and repositories. Or Aldenebai keeps running it with a named response time. What gets built →

Questions about pricing

Why no price list?

Because the same system costs very different amounts depending on integrations, volumes, and guardrails; the section above explains what drives it. The proposal you receive is a fixed price for a fixed scope.

What does fixed scope, fixed price mean in practice?

Before any build, you get a written proposal: what the system does, what it deliberately does not do, its guardrails, its tests, its timeline, and its price. That price does not move unless you change the scope. Surprises are a design failure, and they are designed out.

What is a pilot?

The first system on a slice of real traffic, with its monitoring and tests, and a target named before it starts. The section above describes how it is scoped.

What does a system cost to run?

Running costs are the model usage and infrastructure on your own accounts, visible on your own bills, with a hard monthly ceiling set in the design. There is no Aldenebai licence fee and no per-seat charge.

What happens if Paul is unavailable mid-build?

Nothing is locked to one person. Every system is built inside your own repositories and accounts from the first commit, never on Aldenebai infrastructure, and ships with a runbook, the exported workflows, and its own tests, so any competent engineer can pick it up and run it. There is a team behind Paul for capacity, a defect warranty after go-live, and a kill switch you control. If the engagement ended tomorrow you would keep working software you already own, not a dependency on a supplier.

Do you offer retainers or ongoing support?

Yes, as the Operate option above: Aldenebai monitors the system, tunes thresholds, updates models and prompts, and answers within a named response time, for a monthly fee agreed in the proposal that you can cancel monthly. It is never bundled in by default. Your team can own and run what was built from day one and call only when you want more.

The first step costs nothing.

Thirty minutes, a written map, and a realistic estimate for your first system. Yours to keep either way.

Audit: free, 30 min →