You pay for the audit, then the build, then someone keeping it alive.
We do not publish a price, because we do not quote a build we have not scoped. What we can tell you is exactly how it is priced. The audit is a fixed fee. The build is a fixed fee, quoted only after the audit. The run is monthly.
01 The audit
One job, mapped end to end: which parts are worth programming, and which are not.
A fixed fee, agreed in writing before the audit starts.
What you get
The runbook, yours the day it is delivered
Every step timed and costed
The exceptions named, including the customers who are one
Every system the work touches, listed
A build scope specific enough to hand to someone else
An honest no if AI is the wrong tool
02 Build
quoted after 01
The data layer first, then the workflows on top of it.
One fixed fee for the scope written in the runbook.
Nothing hourly. Nothing licensed.
What you get
A running system you own
The code and the credentials
The documentation, written to be handed over
An exception path for everything it cannot decide
Running inside the systems your team already opens
03 Run
We watch it, fix it, and extend it as your work changes.
A monthly fee, set by how many workflows are live.
Not a seat count. It does not grow when you hire.
What you get
Monitored, with the alert reaching us before it reaches you
The exception queue, watched by a person
Fixes when a supplier changes their format
Fixes when a system changes its interface
Extensions as the work changes
The second workflow, faster to build than the first
Engineers in Dubai, in your timezone
When it breaks at 2am, that is ours
01 The audit
One job, mapped end to end: which parts are worth programming, and which are not.
A fixed fee, agreed in writing before the audit starts.
What you get
The runbook, yours the day it is delivered
Every step timed and costed
The exceptions named, including the customers who are one
Every system the work touches, listed
A build scope specific enough to hand to someone else
An honest no if AI is the wrong tool
02 Build
quoted after 01
The data layer first, then the workflows on top of it.
One fixed fee for the scope written in the runbook.
Nothing hourly. Nothing licensed.
What you get
A running system you own
The code and the credentials
The documentation, written to be handed over
An exception path for everything it cannot decide
Running inside the systems your team already opens
03 Run
We watch it, fix it, and extend it as your work changes.
A monthly fee, set by how many workflows are live.
Not a seat count. It does not grow when you hire.
What you get
Monitored, with the alert reaching us before it reaches you
The exception queue, watched by a person
Fixes when a supplier changes their format
Fixes when a system changes its interface
Extensions as the work changes
The second workflow, faster to build than the first
Engineers in Dubai, in your timezone
When it breaks at 2am, that is ours
What moves the number
The audit
Build
Run
The work itself
How many systems it touches
More to map
More to connect
More to watch
How many exceptions the work carries
More to write down
More paths to build
More that reaches a person
What is fixed, and when
Agreed in writing before it starts
Requires the audit to exist first
Recurs every month
When each one is agreed
Before we start
After the audit
Monthly, from go-live
How each fee behaves
Can be bought on its own
What moves the number
Analysis
The work itself
How many systems it touches
More to map
How many exceptions the work carries
More to write down
What is fixed, and when
Agreed in writing before it starts
Requires the audit to exist first
Recurs every month
When each one is agreed
Before we start
How each fee behaves
Can be bought on its own
What moves the number
Build
The work itself
How many systems it touches
More to connect
How many exceptions the work carries
More paths to build
What is fixed, and when
Agreed in writing before it starts
Requires the audit to exist first
Recurs every month
When each one is agreed
After the audit
How each fee behaves
Can be bought on its own
What moves the number
Run
The work itself
How many systems it touches
More to watch
How many exceptions the work carries
More that reaches a person
What is fixed, and when
Agreed in writing before it starts
Requires the audit to exist first
Recurs every month
When each one is agreed
Monthly, from go-live
How each fee behaves
Can be bought on its own
What moves the number
The audit
Build
Run
The work itself
How many systems it touches
More to map
More to connect
More to watch
How many exceptions the work carries
More to write down
More paths to build
More that reaches a person
What is fixed, and when
Agreed in writing before it starts
Requires the audit to exist first
Recurs every month
When each one is agreed
Before we start
After the audit
Monthly, from go-live
How each fee behaves
Can be bought on its own
You can stop after the audit and take the spec elsewhere
The runbook is yours the day it is delivered. It names the systems, the triggers, the exceptions and the decisions your people actually make, in enough detail that a different team could build from it.
No licence, no seat bill, no per-user charge
No licence, no seat bill, no per-user charge
You own what we build. Nothing on this page is a subscription to software, and the monthly fee is for keeping a system alive rather than for permission to use it.
Send us one thing your team repeats.
Nothing to prepare, and no documents to send first. We come back with what it would take to build and what it would cost to run, and if it is not worth building we say so. No form, no demo, and no call unless you want one.
The alternatives
Four routes to this, and where each one stops.
A consultancy
A software product
A development shop
Your own team
ALREADY CONSIDERED
A consultancy
It ends at the document.
NOT FINISHED
Their partner model is built for engagements far larger than this one. Below that line the document is the profitable part and the build is not.
A document. Your team still runs the work themselves.
They encode your judgment, and it leaves with them when the engagement closes.
ALREADY CONSIDERED
A software product
It ends at the login.
NOT FINISHED
One product has to serve every company that buys it. An engineer sitting inside yours does not survive a product margin.
A login and a seat bill. The exceptions your business runs on are still manual.
You encode it, on your own time, in someone else’s configuration screen.
ALREADY CONSIDERED
A development shop
It ends with your specification built exactly.
NOT FINISHED
They price and staff for build time. Sitting with your team until the specification exists is not in that price.
Software, and the specification problem you started with.
You encode it, in the specification. Writing that specification is the part you were trying to hand over.
ALREADY CONSIDERED
Your own team
It ends at the half-built version.
NOT FINISHED
An internal build runs on whoever has time left over, and every week it competes with the objectives those same people are actually measured on.
A stalled effort, running on one person’s laptop.
Whoever has time that quarter.
Runbook does not stop there.
We encode the judgment your own people already apply, exceptions included. What is left after is a system running in production. Running it is the relationship, and the build is what earns it.
The reason most internal efforts stall at “we built a chatbot” is not the model and not the engineers. It is that what is left is checking every answer against jobs you already finished, the permissions, the exceptions and the reliability your business is judged by, and none of it is the part anyone wanted to build.
The alternatives
Four routes to this, and where each one stops.
A consultancy
A software product
A development shop
Your own team
ALREADY CONSIDERED
A consultancy
It ends at the document.
NOT FINISHED
Their partner model is built for engagements far larger than this one. Below that line the document is the profitable part and the build is not.
A document. Your team still runs the work themselves.
They encode your judgment, and it leaves with them when the engagement closes.
ALREADY CONSIDERED
A software product
It ends at the login.
NOT FINISHED
One product has to serve every company that buys it. An engineer sitting inside yours does not survive a product margin.
A login and a seat bill. The exceptions your business runs on are still manual.
You encode it, on your own time, in someone else’s configuration screen.
ALREADY CONSIDERED
A development shop
It ends with your specification built exactly.
NOT FINISHED
They price and staff for build time. Sitting with your team until the specification exists is not in that price.
Software, and the specification problem you started with.
You encode it, in the specification. Writing that specification is the part you were trying to hand over.
ALREADY CONSIDERED
Your own team
It ends at the half-built version.
NOT FINISHED
An internal build runs on whoever has time left over, and every week it competes with the objectives those same people are actually measured on.
A stalled effort, running on one person’s laptop.
Whoever has time that quarter.
Runbook does not stop there.
We encode the judgment your own people already apply, exceptions included. What is left after is a system running in production. Running it is the relationship, and the build is what earns it.
The reason most internal efforts stall at “we built a chatbot” is not the model and not the engineers. It is that what is left is checking every answer against jobs you already finished, the permissions, the exceptions and the reliability your business is judged by, and none of it is the part anyone wanted to build.
The alternatives
Four routes to this, and where each one stops.
A consultancy
A software product
A development shop
Your own team
ALREADY CONSIDERED
A consultancy
It ends at the document.
NOT FINISHED
Their partner model is built for engagements far larger than this one. Below that line the document is the profitable part and the build is not.
A document. Your team still runs the work themselves.
They encode your judgment, and it leaves with them when the engagement closes.
ALREADY CONSIDERED
A software product
It ends at the login.
NOT FINISHED
One product has to serve every company that buys it. An engineer sitting inside yours does not survive a product margin.
A login and a seat bill. The exceptions your business runs on are still manual.
You encode it, on your own time, in someone else’s configuration screen.
ALREADY CONSIDERED
A development shop
It ends with your specification built exactly.
NOT FINISHED
They price and staff for build time. Sitting with your team until the specification exists is not in that price.
Software, and the specification problem you started with.
You encode it, in the specification. Writing that specification is the part you were trying to hand over.
ALREADY CONSIDERED
Your own team
It ends at the half-built version.
NOT FINISHED
An internal build runs on whoever has time left over, and every week it competes with the objectives those same people are actually measured on.
A stalled effort, running on one person’s laptop.
Whoever has time that quarter.
Runbook does not stop there.
We encode the judgment your own people already apply, exceptions included. What is left after is a system running in production. Running it is the relationship, and the build is what earns it.
The reason most internal efforts stall at “we built a chatbot” is not the model and not the engineers. It is that what is left is checking every answer against jobs you already finished, the permissions, the exceptions and the reliability your business is judged by, and none of it is the part anyone wanted to build.
Questions
Seven questions we get asked.
Still have a question?
Message us on WhatsApp and describe it. We come back with what it would take to build and what it would cost to run.
How long does it take?
The scope, the fee and the finish date are agreed with you in writing before anything starts. We do not publish a length, because it follows the size of the business, how many systems the work touches and what condition the data is in. The build is quoted only after the audit, because we do not quote work we have not scoped.
Do we have to move our data?
No. We build a layer that reads what you already have, wherever it lives. An ERP, a shared drive, WhatsApp, a rate card in Excel. Moving your data is a different project and it is not this one.
What happens when it gets something wrong?
The agent is built to know when it cannot be sure. At that point it stops and tells a named person, with the reason. The exceptions are written down in phase 01, so they are part of the spec rather than a surprise in phase 03.
Who owns it when you leave?
You do. The code, the credentials, the documentation and the exception paths sit in your accounts and under your name from the day we start. You can also stop after the audit and take the runbook to another team.
Does this replace people?
It replaces the part of a role that is repeated, which is usually the part nobody enjoys. We will not tell you it never changes a headcount. Sometimes it is the reason you do not need the next hire.
What if our process is not written down anywhere?
That is the normal case and it is what phase 01 is for. We write the work down, timed and costed, and you own that document whatever you decide next.
How is this different from hiring a developer?
A developer builds what you specify, and the specification is the hard part. We write it first, by sitting with the people who do the work, then build it, then run it.
Questions
Seven questions we get asked.
Still have a question?
Message us on WhatsApp and describe it. We come back with what it would take to build and what it would cost to run.
How long does it take?
The scope, the fee and the finish date are agreed with you in writing before anything starts. We do not publish a length, because it follows the size of the business, how many systems the work touches and what condition the data is in. The build is quoted only after the audit, because we do not quote work we have not scoped.
Do we have to move our data?
No. We build a layer that reads what you already have, wherever it lives. An ERP, a shared drive, WhatsApp, a rate card in Excel. Moving your data is a different project and it is not this one.
What happens when it gets something wrong?
The agent is built to know when it cannot be sure. At that point it stops and tells a named person, with the reason. The exceptions are written down in phase 01, so they are part of the spec rather than a surprise in phase 03.
Who owns it when you leave?
You do. The code, the credentials, the documentation and the exception paths sit in your accounts and under your name from the day we start. You can also stop after the audit and take the runbook to another team.
Does this replace people?
It replaces the part of a role that is repeated, which is usually the part nobody enjoys. We will not tell you it never changes a headcount. Sometimes it is the reason you do not need the next hire.
What if our process is not written down anywhere?
That is the normal case and it is what phase 01 is for. We write the work down, timed and costed, and you own that document whatever you decide next.
How is this different from hiring a developer?
A developer builds what you specify, and the specification is the hard part. We write it first, by sitting with the people who do the work, then build it, then run it.
Questions
Seven questions we get asked.
Still have a question?
Message us on WhatsApp and describe it. We come back with what it would take to build and what it would cost to run.
How long does it take?
The scope, the fee and the finish date are agreed with you in writing before anything starts. We do not publish a length, because it follows the size of the business, how many systems the work touches and what condition the data is in. The build is quoted only after the audit, because we do not quote work we have not scoped.
Do we have to move our data?
No. We build a layer that reads what you already have, wherever it lives. An ERP, a shared drive, WhatsApp, a rate card in Excel. Moving your data is a different project and it is not this one.
What happens when it gets something wrong?
The agent is built to know when it cannot be sure. At that point it stops and tells a named person, with the reason. The exceptions are written down in phase 01, so they are part of the spec rather than a surprise in phase 03.
Who owns it when you leave?
You do. The code, the credentials, the documentation and the exception paths sit in your accounts and under your name from the day we start. You can also stop after the audit and take the runbook to another team.
Does this replace people?
It replaces the part of a role that is repeated, which is usually the part nobody enjoys. We will not tell you it never changes a headcount. Sometimes it is the reason you do not need the next hire.
What if our process is not written down anywhere?
That is the normal case and it is what phase 01 is for. We write the work down, timed and costed, and you own that document whatever you decide next.
How is this different from hiring a developer?
A developer builds what you specify, and the specification is the hard part. We write it first, by sitting with the people who do the work, then build it, then run it.