Evaluation scope
Start from the workflow you need to prove first.
Pricing and deployment
Pricing depends on workflow scope, deployment shape, and the controls your team needs. This page is organized around those choices, not seat-count theater.
Needs in
Evaluation scope
Start from the workflow you need to prove first.
Deployment need
Cloud, private, or embedded rollout changes the track.
Render path
Match deployment shape and workflow scope before talking about plan names.
Rollout out
Deployment option
Choose the operating model your team can support.
Expansion path
Move from first team to broader rollout without a reset.
Pricing works better when it is tied to rollout shape and ownership, not a pile of disconnected labels.
How to evaluate: Start with template complexity, deployment boundaries, and who will run the workflow after rollout.
For teams proving out templates, authoring speed, and the first delivery workflows.
For organizations moving quotes, reports, statements, and packs into daily production.
For teams standardizing document delivery across products, business units, or regulated environments.
Deployment models
Packaging only matters if the deployment model can pass security review, operating review, and team reality.
Run the product inside controlled infrastructure without changing the user workflow.
Deploy with clear service boundaries for the app, workers, storage, queue, and converters.
Embed generation into your product without assembling the full document stack yourself.
Included in evaluation
Walk the current rendering pipeline, data model, and governance constraints.
Validate format coverage and identify the fastest proof points for your document inventory.
Map the path from evaluation into governed production use.
Next Step
Pricing becomes clearer once we understand template complexity, deployment boundaries, document volume, and rollout goals.
In the session