Fixed-price discovery and the systems integrator margin problem

Pricing what you cannot see

Clients increasingly want modernization delivered on fixed price, or at least with a fixed-price build phase after a short discovery. It is a reasonable request: they have been through time-and-materials programs that never ended. For the integrator, it moves the risk of the unknown onto its own margin.

The unknown is mostly in the legacy system's behavior. The bid team estimates build effort from a requirements baseline, and that baseline comes from discovery. Every business rule discovery misses turns up later, as a defect in system test, a failed reconciliation in parallel run, or a change request the client disputes because, from their side, the new system was always supposed to do what the old one did. The practice lead I hear this from most often puts it plainly: we do not lose money on code we estimated, we lose it on code we did not know existed.

Worked arithmetic for a 2 million line program

Take a fictional but typical engagement: a regional insurer's policy administration system, about 2,000,000 lines of COBOL and CICS, with a twelve month build phase planned after discovery. PYD ENTERPRISES' own engagement benchmarks put manual discovery at $0.40 to $0.75 per line of code, depending on code quality and the availability of people who know the system. Those are our figures, measured on our engagements, not an industry survey.

• Manual discovery: 2,000,000 x $0.40 to $0.75 = $800,000 to $1,500,000
• Calendar time at typical staffing: several months before the build estimate is firm
• Coverage: whatever the team read, which is never everything

Now the margin side. Suppose the build phase is priced at $9,000,000 with a 22% target margin, so about $1,980,000 of gross profit. If rules missed in discovery generate rework worth 8% of the build price ($720,000), and the integrator absorbs half of it, that is $360,000 of margin gone, about 18% of the profit on the deal. Nothing in that arithmetic is exotic. It is one missed calculation path per few hundred programs.

What changes with a rule inventory

Automated discovery does not remove the analysts from the program. It changes what they spend their time on and what the bid is built from.

1. Week one: PYD ENTERPRISES runs inside the client's environment, parses the full codebase and produces the dependency graph, the data lineage and a first rule inventory.
2. Weeks two and three: the integrator's architects and the client's business analysts review extracted rules beside their source lines, mark fossils, and confirm the rules the new system must keep.
3. Bid: the build estimate is priced from a counted, signed inventory: so many decision tables, so many formulas, so many interfaces described in OpenAPI 3.1, with every item traceable to code.

The contract can then reference the inventory. A rule in the signed inventory is in scope. A rule the client adds later is a change, and both sides can see that it was not in the code. That alone takes most of the heat out of change request negotiations.

How the partner license is structured

For integrators running many discovery phases a year, buying a Discovery Scan per system does not fit the sales cycle. The Global SI Partner license starts at $150,000 a year with unlimited scans across client engagements, white-label discovery reports in the integrator's own format, and parser customization for client-specific dialects. Partners typically run PYD ENTERPRISES in the first two weeks of a discovery phase and price the remainder of the program from the extracted inventory.

The economics are straightforward to check. If the license removes even a fraction of manual discovery cost on two mid-sized engagements, it has paid for itself before margin protection is counted. The ROI calculator lets bid teams run their own numbers, and the systems integrators page covers delivery models.

What it does not do

It is worth being explicit, because bid teams are rightly skeptical of tools that promise to automate modernization. PYD ENTERPRISES does not translate COBOL into Java, and it does not write the target application. The build is still the integrator's work, and its quality is the integrator's differentiator. What changes is that the build starts from a specification the client has signed and a test suite derived from the legacy system's own branches, rather than from interview notes.

It also does not claim to find every rule by magic. It accounts for every executable path: extracted as a rule, classified as plumbing, or flagged for review. The flagged items are the honest part of the inventory, and pricing them explicitly, as a review backlog with an owner, is better than discovering them in month nine.

Running the first one

Most partners start with one live bid. We run the scan alongside the integrator's architects, the white-label report goes into the proposal, and the practice compares the counted inventory against the manual estimate it would otherwise have used. If you lead a modernization practice, talk to partnerships and bring a bid you are working on now.