A deployment is three things bought together, in proportions that depend on your company - so a single figure on this page would be a guess dressed up as an answer. What we can show you is all three parts, what moves each of them, and how the first step works, so you can judge the size of this before you talk to anyone.
Three components, always the same three. What changes between one company and the next is how much of each you need.
The environment itself and its upkeep - updates, new components as they arrive, and the work of keeping it healthy on your infrastructure. This is the part that behaves most like a subscription.
Connecting it to your world: gateways to the systems you already run, integrations, search over your own material, single sign-on against your directory, audit, the models you will use - and the work of making all of it behave as one system rather than a pile of parts.
Understanding what you actually expect, how your processes really run rather than how the procedure says they do, and turning that into technical requirements. This is the part that decides whether everything built on top of it is worth having.
One or two processes, a selected group of people, a defined end date. Enough to watch the platform work on your own material and your own permissions instead of in a demonstration.
What we will not pretend: a pilot covering two processes usually still needs the whole platform underneath it. Identity, gateways, audit and the components everything else stands on do not come in a smaller size. That is why a pilot is real work rather than a token exercise, and why we price it as such.
It is also why what you pay for the pilot is credited in full against the deployment that follows. You do not buy the same platform twice. The pilot buys you the answer to a question no proposal can settle: whether this changes anything in your company.
You can estimate roughly where you sit before we ever speak. Most of what drives the figure is about your environment, not about us.
Many systems to connect, especially ones without a usable interface. Models running entirely on your own hardware. Processes that exist in people's heads rather than anywhere in writing. A directory and group structure that has to be tidied before anything can rely on it. Strict audit or regulatory requirements that have to be evidenced rather than asserted.
A first process that is already clear and genuinely worth automating. Systems that expose their data properly. Identity and permissions you already trust and maintain. A willingness to start with managed models and move them in-house later - the platform treats that as a setting, not a rebuild.
If your processes are not written down anywhere, that is not a disqualification - it is usually the first thing we do together, and it has value whether or not you deploy anything afterwards.
You receive the source code in your own private repository, including everything we built for you, and you keep the right to use it after our work together ends. Your documents, your indexes, the skills that encode how your company works and the record of what was run and what it cost stay in your environment, in formats you can read without us. The components underneath are open. Ending the relationship means losing our help, not losing the system.
Thirty minutes on a single process tells us more than a requirements document, and tells you more than a proposal. You will leave knowing roughly what a pilot on it would involve.
Scope your pilotPaid pilot · one or two processes · scope agreed on the first call