A fixed price, agreed before we start
Every engagement has a fixed, guaranteed price, set after we analyse your package and its real scope. No subscription, no usage-based fees, no hidden costs.
- Fixed, guaranteed price
- No subscription
- No usage-based fees
- No hidden costs
You know what you'll spend before any work begins
The price is based on the real scope we analyse, not on a consumption estimate. What's included is written into the offer before work starts.
Fixed and guaranteed
The agreed price doesn't change during execution. Only a change to the requirements after kick-off calls for a new run, to be agreed.
Based on the real scope
Size and composition of the scope: mainly the lines of active logic, excluding comments and blank lines, and the complexity of the environments involved.
No subscription, no usage fees
No charges tied to usage, no GPUs or infrastructure to build and maintain, no subscriptions to external models.
Everything in writing up front
Scope, success criteria, deliverables and timing are defined in the offer or the PoC agreement before work begins.
Start with the PoC, continue with the engagement
Same rules, same package, same method: the PoC applies them to a smaller scope. If the outcome is positive, instructions, tests and package are reused on the next scope.
Proof of Concept
Proves on your own code, with a limited commitment, that the result is functionally equivalent to the original and complies with your rules.
- Closed scope of up to 30,000 lines, excluding comments and blank lines
- Success criteria you define before kick-off
- A single pass, with instructions and tests frozen at kick-off
- PoC agreement covering scope, success criteria, deliverables and timing
- Delivery of code, tests, data sets, documentation and validation evidence
Engagement
Migration of the full scope, with the same completion criterion: every test and quality gate passed, including differential tests against the original.
- No 30,000-line limit: the scope is whatever needs migrating
- Offer drawn up after analysing the package
- Price based on lines of active logic and environment complexity
- What's included is defined in the offer before kick-off
- Instructions, tests and package from the PoC are reused
From scope to fixed-price proposal, in three steps
The price comes from analysing your actual code, so the first step is telling us about the scope.
- 01You
Send us the scope
Tell us about languages, size and goals using the request form. Once the NDA and the code ownership declaration are signed, you send the package: sources, target instructions, tests and data.
- 02Scriba
Eligibility analysis
Source inventory, line count, scope closure check and a list of unresolved references. This is where our clarification questions are concentrated.
- 03You and Scriba
Fixed-price proposal
You receive the PoC agreement or the engagement offer, with scope, success criteria, deliverables, timing and price, all defined before kick-off.
The package is delivered via encrypted storage with an expiring link or a private Git repository, cleaned of credentials, production endpoints and real personal data.
The price covers everything you need to verify the result
Not just the code: you get the means to prove that the migrated system behaves like the original, even in front of an independent reviewer.
Migrated code
A complete, idiomatic repository that complies with instructions.md: project structure, dependencies, database schema and build configuration.
Test suite
Tests generated according to test.md, built into the build and re-runnable by your team, including equivalence tests against the original system.
Validation evidence
Test results, coverage, quality gates and static analysis, with a report linking every requirement to the evidence that it has been met.
Data sets
Test datasets, fixtures and seeds, record layout mappings, load scripts and the target schema, reusable in later acceptance testing.
16 documents
The standard set numbered 00 to 15, from the executive summary to the operations runbook, or the documents you list in docs.md.
Traceability
Source → target map, extracted business rules referenced back to the source, and explicitly declared technical debt.
The standard documentation set
Written for management (01) and for development and validation teams (02–15).
- 00Index
- 01Executive summary
- 02Source analysis
- 03Target architecture
- 04Compatibility components
- 05Translation strategy
- 06Program mapping
- 07Database and schema
- 08API
- 09Frontend
- 10Validation and testing
- 11Performance
- 12Change history
- 13Technical debt
- 14Operations runbook
- 15Glossary
Integration with live systems, migration of production data and acceptance testing in your environments are included only if declared in the scope.
How predictable is the cost, and who answers for the result
Sooner or later, every approach produces code that compiles. What differs is how predictable it is to get there, and who takes responsibility for the result.
| Approach | Cost predictability | Accountability for the result |
|---|---|---|
| Manual rewrite | Low | The team's or the vendor's |
| Commercial conversion tools | Medium: licences | On the tool, not the result |
| General-purpose LLMs | Low on large scopes | Yours |
| Agents on commercial LLMs | Low: token consumption | Yours |
| Agents on open-source LLMs | Medium: infrastructure | Yours |
| Scriba AI | Fixed, guaranteed price | Scriba's, until every gate is passed |
Ratings describe the typical behaviour of each approach; individual tools or projects may differ.
Frequently asked questions about pricing and terms
How are the commercial terms defined?
For the PoC, they're set out in the PoC agreement, before kick-off. For an engagement, after analysing the package, based on the actual size and composition of the scope, at a fixed, guaranteed price. In both cases, with no subscriptions and no usage-based fees.
What does the price of an engagement depend on?
On the actual size and composition of the scope, measured when we analyse the package: mainly the lines of active logic, excluding comments and blank lines, and the complexity of the environments involved.
Are there costs for models, GPUs or infrastructure?
No. Scriba uses no LLMs and never sends your code to model providers: there are no external model subscriptions, no usage-based fees, no GPUs or pipelines to build and maintain. You have a single party accountable for the result.
Our scope is larger than 30,000 lines. What can we do?
Identify a closed sub-process within it that fits the limit, or go straight to an engagement, with a fixed-price offer after the package has been analysed.
Can we change the requirements after kick-off?
Clarifications are resolved during the eligibility check, before kick-off. After kick-off, instructions and tests are frozen: a change to the requirements calls for a new run, to be agreed.
What do we keep at the end of the PoC?
Code, tests, data sets, documentation and validation evidence. If the PoC scope is part of the following engagement, the material produced and the package you prepared are reused.
Do we depend on Scriba after delivery?
No. The code is maintained by your team or the partner of your choice: it's structured according to your conventions and comes with tests, data and documentation precisely to make that possible.
Get a fixed price for your scope
Tell us about the code you need to migrate: we analyse the scope and propose a PoC or an engagement at a fixed, guaranteed price.