You own everything we build.
It runs in your cloud account. If you stop paying us, it keeps running. What stops is us watching it, fixing it and extending it. We do not publish a price, because every build is fitted to one institution. The build is a fixed fee. The run is monthly.
It runs in your cloud account. If you stop paying us, it keeps running. What stops is us watching it, fixing it and extending it. We do not publish a price, because every build is fitted to one institution.
1 Build
agreed in writing
The data layer first, then the runbooks on top of it.
One fixed fee for the runbooks you name.
Nothing hourly. Nothing licensed.
What you get
A running system, in your own cloud account
The runbooks, live in the systems you already use
Every runbook proven on your hardest cases
An exception path for everything it cannot decide
The code and the credentials, under your name
2 Run
We watch it, fix it, and extend it as your work changes.
A monthly fee that follows the runbooks you have 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
Engineers in Doha, Dubai and Abu Dhabi, in your timezone
When it breaks at 2am, that is ours
1 Build
agreed in writing
The data layer first, then the runbooks on top of it.
One fixed fee for the runbooks you name.
Nothing hourly. Nothing licensed.
What you get
A running system, in your own cloud account
The runbooks, live in the systems you already use
Every runbook proven on your hardest cases
An exception path for everything it cannot decide
The code and the credentials, under your name
2 Run
We watch it, fix it, and extend it as your work changes.
A monthly fee that follows the runbooks you have 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
Engineers in Doha, Dubai and Abu Dhabi, in your timezone
When it breaks at 2am, that is ours
What moves the number
Build
Run
The work itself
How many systems it touches
More to connect
More to watch
How many exceptions the work carries
More paths to build
More that reaches a person
What is fixed, and when
Agreed in writing before it starts
Recurs every month
When each one is agreed
Before the build starts
Monthly, from go-live
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
Recurs every month
When each one is agreed
Before the build starts
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
Recurs every month
When each one is agreed
Monthly, from go-live
What moves the number
Build
Run
The work itself
How many systems it touches
More to connect
More to watch
How many exceptions the work carries
More paths to build
More that reaches a person
What is fixed, and when
Agreed in writing before it starts
Recurs every month
When each one is agreed
Before the build starts
Monthly, from go-live
Four routes to this, and where each one stops.
Their partners are paid for advice, and the margin sits in the document.
A document. Your team still runs the work themselves.
They encode your judgment, and it leaves with them when the engagement closes. Runbook ends in production, and the rules stay yours.
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. Runbook learns it from your people before anything is built.
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.
Runbook works the specification out with your team.
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. The last ninety percent nobody wanted to build is Runbook’s whole job.
Runbook does not stop there.
The system is not the smart part. Your people are. We make their judgment run, exceptions included. What comes out is a system in production. Running it is the relationship, and the build is what earns it.
Most internal efforts stall at “we built a chatbot”. Not the model. Not the engineers. What is left is the checking, the permissions, the exceptions, and the reliability your business is judged by. None of it is the part anyone wanted to build.
The detail
Everything the number is written against.
What the build and the run cover is on the two cards above. Open a chapter to see what stands behind it.
Questions
The questions we get asked.
Still have a question?
Describe it in the booking form. If it is worth building, the first meeting is thirty minutes with the people who would build it.
What does the first meeting cost?
Nothing. It is thirty minutes with the people who would build it: the job as it runs today, where the line would sit, and what we would measure.
We already use AI. Is this still for us?
Yes, and it is usually the fastest start. If someone built you a copilot, we prove whether it can be trusted and hand you the test set that decides. If your AI works but the bill keeps growing, we bring the cost down and prove nothing got worse. Both are fixed fees.
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.
Do we have to move our data?
No. Runbook OS 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 named before go-live, and anything it cannot decide goes down the exception path.
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.
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. The build starts with the people who do the work, and what they know is written down as the rules each runbook runs on.
How is this different from hiring a developer?
A developer builds what you specify, and the specification is the hard part. We take that part on, then build and run what comes out of it.
Questions
The questions we get asked.
Still have a question?
Describe it in the booking form. If it is worth building, the first meeting is thirty minutes with the people who would build it.
What does the first meeting cost?
Nothing. It is thirty minutes with the people who would build it: the job as it runs today, where the line would sit, and what we would measure.
We already use AI. Is this still for us?
Yes, and it is usually the fastest start. If someone built you a copilot, we prove whether it can be trusted and hand you the test set that decides. If your AI works but the bill keeps growing, we bring the cost down and prove nothing got worse. Both are fixed fees.
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.
Do we have to move our data?
No. Runbook OS 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 named before go-live, and anything it cannot decide goes down the exception path.
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.
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. The build starts with the people who do the work, and what they know is written down as the rules each runbook runs on.
How is this different from hiring a developer?
A developer builds what you specify, and the specification is the hard part. We take that part on, then build and run what comes out of it.
Questions
The questions we get asked.
Still have a question?
Describe it in the booking form. If it is worth building, the first meeting is thirty minutes with the people who would build it.
What does the first meeting cost?
Nothing. It is thirty minutes with the people who would build it: the job as it runs today, where the line would sit, and what we would measure.
We already use AI. Is this still for us?
Yes, and it is usually the fastest start. If someone built you a copilot, we prove whether it can be trusted and hand you the test set that decides. If your AI works but the bill keeps growing, we bring the cost down and prove nothing got worse. Both are fixed fees.
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.
Do we have to move our data?
No. Runbook OS 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 named before go-live, and anything it cannot decide goes down the exception path.
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.
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. The build starts with the people who do the work, and what they know is written down as the rules each runbook runs on.
How is this different from hiring a developer?
A developer builds what you specify, and the specification is the hard part. We take that part on, then build and run what comes out of it.