Have a contract?
Import it.
The signed SOW becomes the baseline everything else is measured against.
Intovia connects contracts, requirements, architecture, delivery and testing — so changes don't quietly break the meaning of the work.
Come in at any point in the chain. You don't have to start at the beginning.
Recall reminder workflow
“Reply answered within 2 hours”
Implement escalation path
Two-hour response scenario
Start with what you have
Most engagements are already half-documented by the time anyone wants order. Intovia takes you in wherever you actually are.
Import it.
The signed SOW becomes the baseline everything else is measured against.
Start there.
Bring documents, a call, an email thread or your own notes. Skip discovery entirely.
Analyse it.
See which contractual promises your stories actually claim to build.
Check them against the contract.
Find the obligations a story claims but no scenario reaches.
Run a traceability check.
Every obligation, and whether it is built, tested — or neither.
From agreement to delivery
That is the whole difference. A restatement drifts; an inheritance carries the ids with it, so a change upstream is findable downstream.
Turn approved requirements into a contract — deliverables, acceptance criteria, and a price from your own rate card.
Turn the contract into a solution design. Components, decisions and their reasons, integrations, and where personal data lives.
Turn commitments into buildable work. Every story names the deliverable it builds and the criteria it satisfies.
Prove the agreed work can be validated. Every scenario names the stories it verifies, in given / when / then.
Understand what a change actually affects — before anyone starts building it — and what it costs against the rate card.
Send agreed, traceable work into execution with its ids intact.
Change impact
A client sentence lands in your inbox on a Tuesday. By Thursday two people have started work on their own reading of it. The cost of that is never in the change request — it is in the rework nobody priced.
“Add a cancellation waiting list — if someone drops out, offer the slot to the next person automatically.”
Statement of Work
Acceptance criteria
User stories
Test scenarios
Traceability & coverage
A story saying it builds an obligation is a claim. A scenario reaching that obligation through the story is proof. Intovia keeps the two apart, and tells you which promises have neither.
That last row is the one worth the licence fee. It is a promise in a signed contract that nothing in the delivery plan has picked up — and without a join across the whole chain, nobody finds it until the client does.
What we will not do
Six rules, and they cost you clicks. What they buy is that nothing on a page here is more confident than the thing behind it.
Pricing
A document is a brief, a Statement of Work, a delivery plan, a contract amendment or an imported contract. Talking to your clients is not: discovery, the client room and their answers are unlimited on every plan.
Enough to put one real engagement through and judge the output.
For an agency running a handful of engagements at a time.
For a practice where proposals are continuous rather than occasional.
If your work does not fit three plans — a volume nobody has, a deployment somewhere particular — tell us what you need and we will tell you honestly whether it exists yet.
Prices in USD. Every plan includes the whole chain — only how much you run changes, so nobody loses traceability by being on the smaller tier.
Discovery, requirements, contract, architecture, delivery plan, tests and change — on every plan.
Every run recorded, versioned, and held behind a person where a document reaches a client.
Client conversations, answers and the client room are unlimited. Charging for the questions would be charging for the part that makes everything after it better.
The month is a calendar month in UTC. At the limit new documents wait; nothing already produced is touched.
Questions
That is one of the better places to start. Import the contract and it becomes the baseline — you can then generate architecture, a delivery plan and tests from it, or check a delivery plan you already have against it.
No. Intovia covers what was agreed and whether the work proves it. Where your team tracks tickets is your business — and pushing agreed work into Jira is on the roadmap, not shipped.
Every acceptance criterion in the contract is joined to the stories that claim to build it and the scenarios that reach it. Three answers come out: claimed and reached, claimed with nothing reaching it, and claimed by nothing at all. None of them means the software has been proven to work.
Every requirement carries the quotation it came from, checked back against the source it claims to come from. Where the analysis had to assume something, the assumption is recorded as an open question rather than written into a requirement.
Not without you. Anything outbound is held until a person releases it, with the full content on the approval screen rather than behind a link.
A brief, a Statement of Work, a delivery plan, a contract amendment, an imported contract or a change draft. A re-run counts, and so does a run that fails part-way — the work was done either way. Reading the coverage report on work you already have does not.
Get started
The interesting question is not whether Intovia produces documents. It is whether every line of them traces back to something the client agreed to — and which promises, on the job you already shipped, nothing ever tested.