Define it with us. Then a fixed price to build it.

Two phases, for a legacy rebuild, a new SaaS product or an internal system. Define it with us and end with a prototype you can click through, then have it built for a fixed price quoted from what you approved. We carry the delivery risk in the build because our cost is set by tooling, not headcount.

The offer

Phase 1, Define: Per diem, or a small fixed fee. Ends with a working prototype on mocked data, the API contract behind it, the acceptance scenarios in Gherkin, and the non-functional targets: speed, accessibility, security, availability, recovery and residency, each with a measured threshold. Yours to keep, whether or not there is a Phase 2.
Phase 2, Build: A fixed price, quoted from the prototype and targets you approved, not from a rate card. The quote shows its working: build, non-functional work, support for your UAT, and the reserve for fixing UAT defects.
Acceptance: Mechanical. The journeys you signed off in Phase 1 pass against the real system, and every non-functional target passes its automated check, so "done" cannot drift.
Client UAT: A defect is a signed scenario that fails or a signed target that is missed. We fix defects within the UAT window at no charge; that cost is already in the price. New asks are priced changes, estimated the same way.
Payment: Against delivery milestones you accept, with the balance on final acceptance. Nothing is billed for time in Phase 2.
Risk: Ours in Phase 2. We quote after we have read the code and you have approved the screens, so estimation error is our problem, not yours. A vendor who bills by the hour is paid more when the work takes longer. We are not.

The structure is deliberate. The phase where nobody can know the scope is billed as work. The phase where the scope is approved is billed as a price. The same two phases apply to a new product as to a legacy rebuild.

Why the economics work

The expensive part of any system is agreeing what it should do; in legacy modernization that means working out what the old code does. Writing the new code is not where the money goes. We do that once, with tooling, into a structure every later application reuses.

Three things move cost off headcount:

Extraction is automated and deterministic. Source is parsed into an abstract syntax tree and a call graph, not read by an analyst. The output is a specification with a traceable link back to the line of code it came from.
The portfolio is one graph, not N projects. Shared files, batch chains and data dependencies are discovered once. Application 12 inherits everything learned from applications 1 through 11.
The build runs through a gated lifecycle we already own. A versioned template of commands, conventions and quality gates. Requirements are reviewed before design, tests are sealed before implementation, and the implementer cannot edit the tests.

The result is that marginal cost per application falls as the portfolio progresses. That is what makes a fixed price safe for us to quote and useful for you to buy.

When this is the right call

Six situations we see most often, in government and in private-sector companies across Canada and the United States: banks, insurers, credit unions, lenders, and mid-size firms whose core systems have outlived the people who built them.

A core-platform migration is scheduled: Core banking, policy administration, loan origination or property management moving to a new platform on a date. The surrounding applications and batch chains nobody documented are on the critical path. We recover their specification before the date, so the migration plan rests on what the code does rather than on what people remember.
Two estates after a merger: Integration means deciding, behaviour by behaviour, which system's rule survives. That decision needs both sides specified to the same standard. One graph across both estates makes the overlap and the conflicts visible.
A regulator's finding: When a finding asks how a determination was made, the answer has to be traceable. Rebuilding the affected process with every rule cited to its source, and every model-read value verified, is what our tooling does by default.
Legacy skills you can no longer hire: Postings for RPG, COBOL or AS/400 skills going unfilled means the pain is current, and the people who could explain the system are leaving. Discovery captures what they know into a specification while they are still there.
Something new to build: A SaaS product, an internal system, an integration nobody wants to own. Phase 1 starts from your requirements instead of from code, and still ends with a prototype you can click through before a price is quoted. Three of the products we run ourselves started exactly this way.
New technology leadership: A new leader re-opens vendor decisions in the first two quarters. A fixed-price pilot on two or three applications is a decision they can take alone, with a known cost and a mechanical definition of done.

How it works

Two phases, one gate between them. The unknowns live in Phase 1. The fixed price is quoted after it, once you have clicked through the result.

Phase 1
Define
Per diem, or a small fixed fee
- Legacy code read with tooling, every rule cited to its line. Or requirements drawn out in interviews.
- Keep, change, drop, add: decided together.
- Out: a clickable prototype on mocked data, the API contract, the Gherkin scenarios, and measurable non-functional targets.
Client gate. You sign off the set. We quote a fixed price. Stop here if you like; it is yours.
Phase 2
Build
Fixed price, paid on delivery
- Built through our gated lifecycle. Tests sealed before code.
- Accepted against the scenarios and the non-functional targets you signed.
- UAT defects fixed free within the window. New asks priced.
Client gate. Milestones accepted and paid as delivered. Balance on final acceptance.

What we are proposing

Start with Phase 1 on one system, or a slice of one. Small enough to say yes to, and it ends with a prototype and a specification you keep.

It answers the questions no proposal can answer on paper: what the system really has to do, what it really costs to build, and whether the working relationship holds. For a legacy estate it also shows how much of the old behaviour the tooling recovers and how far the dependency graph can be trusted, which is what prices the rest of the estate. If the answer is yes, the Phase 2 quote is already on the table. If not, you have spent a small, known amount to find that out early.

What we need to run it: one person who knows what the system must do, access to the source code if there is one, and a definition of what acceptance means to you. Nothing else.

On language coverage, plainly: our extractor reads a wide set of modern and older languages today. A platform-specific dialect it has not met before, IBM i RPG and CL for instance, needs a reader built for it first. That work is part of Phase 1 and billed in it. Phase 1 is the right place to prove it, rather than a proposal paragraph.

Where we fit beside a larger firm: on a government bid, the named subcontractor for discovery, specification recovery and portfolio sequencing. In a company, the discovery and specification team working beside your existing integrator or in-house developers. Either way, it is the part of a legacy program that is hardest to make credible, and the part that carries the most schedule risk once the work starts.

Book a 30-minute call How we work