The film Moneyball (2011) inspired the founder of Digital Polygraph. Billy Beane replaced scouts' intuition with statistics — and won with half the budget of his competitors. We applied the same logic to software projects: instead of the feeling "we'll manage in a year" — a deterministic engineering calculation that does not know how to flatter.
Cases — Applied Method in Action
The cases in this section are not marketing stories or product feature illustrations. They are examples of applying the patent-pending method protected by a Ukrainian patent application. Each case follows the same procedure: a real project is translated into model parameters, the calculator performs the calculation, and the result becomes the basis for a management decision.
Every case is reproducible. If you open the calculator and select the same functions, the same complexity characteristics, and the same route — you will get an identical result. This is not a demonstration — it is proof of the method.
Six cases cover six typical management situations faced by any software development project. All six are built on a single subject domain — urban transportation infrastructure. This is intentional: a unified domain allows comparing cases against each other and seeing how changes in scale, complexity, or stage configuration affect the calculation result.
The calculator does not know what a tram or funicular is. It knows functions, complexity, innovation, reuse, and lifecycle stages. The transportation domain is just a wrapper. The method is universal.
Invest & Deliver
Transit Access Control System
The project is feasible — but only with the right team configuration. The calculator shows how to control duration by adjusting headcount per stage.
Do Not Start
Unified Metropolitan Transit Control System
Labor intensity is such that no team configuration fits the market window. This is not an opinion — it is mathematics.
Prototype First
Metro Real-Time Control Prototype
Technical feasibility is unproven. Full funding before the prototype demonstration is a reckless investment. The calculator computes the entry cost to checkpoint.
Shared Delivery
Bus & Trolleybus (BT) Access Control Fast Track
The customer takes responsibility for part of the lifecycle stages. The vendor delivers only TWP. A Scrum team of 8 delivers a Release Candidate in 1.22 years.
Ready Spec
Rail Passenger Access System — Ready Spec
The Technical Assignment is provided by the customer. Skipping TA and PP saves 350 pd and nearly a year. First artifact delivered at 0.77 years.
Strategy Matrix
Funicular Access Control System
One project, four routes, one team. The calculator compares all configurations and turns strategic choice into measurable parameters.
Summary
| # | Project | Choice | Functions | Total Labor | Duration | Delivery Model | Verdict |
|---|---|---|---|---|---|---|---|
| 1 | Transit Access Control System | TA→PP→TP→WP→IM | 5 | 3 541 pd | 3.36 yrs | Full Turnkey | Open Path |
| 2 | Unified Metropolitan Transit Control System | TA→PP→TP→WP→IM | 11 | 10 639 pd | 5.70 yrs | Full Turnkey | Closed Path |
| 3 | Metro Real-Time Control Prototype | TA→PP (H1 target) | 5 | 7 930 pd | 1.43 yrs to H1 | Full Turnkey | Prototype First |
| 4 | Bus & Trolleybus (BT) Access Control Fast Track | TWP only | 6 | 2 287 pd | 1.22 yrs | Pure Dev Contract | Shared Delivery |
| 5 | Rail Passenger Access System — Ready Spec | TA(0)→TP→WP→IM | 6 | 3 059 pd | 2.66 yrs | Implementation Partnership | Fast Entry |
| 6 | Funicular Access Control System | C1–C4 comparison | 4 | 3 084–3 160 pd | 3.46–4.23 yrs | Full Turnkey | Strategy Matrix |
Glossary
The method is based on a one-to-one correspondence between engineering lifecycle stages (waterfall model) and product maturity stages (modern development model). This correspondence is the core of the patent-pending method.
| Abbr. | Engineering Stage | Product Stage | Product Maturity | Meaning for VC |
|---|---|---|---|---|
| TA | Technical Assignment | Discovery / Requirements Baseline | Requirements Baseline | Scope is formally defined. You know what you are funding. |
| PP | Preliminary Project | Prototype (conceptual) | Conceptual Maturity | First tangible artifact. Concept is verifiable. First checkpoint. |
| TP | Technical Project | MVP (technical form) | Technical Maturity of MVP | Core architecture is proven. Engineering foundation is ready. |
| WP | Working Project | Release Candidate | Full Engineering Maturity | Feature-complete. Ready for acceptance testing. |
| TWP | Techno-Working Project | Release Candidate (without MVP) | Combined Implementation Maturity | TP + WP merged into one stage. Faster path, fewer artifacts. |
| IM | Implementation | Production Release | Operational Maturity | Live deployment. Product is in production. Investment is delivered. |
| Total | Integral Stage | All selected stages combined | Full Lifecycle Maturity | Total labor and duration for the chosen configuration (Choice). |
| pd | person-days | — | — | Unit of labor intensity. 1 pd = 1 developer working 1 day. |
| FTE | Full-Time Equivalent | — | — | Number of full-time developers assigned to a stage. |
| Choice | Stage Configuration | — | — | Selected combination of engineering stages for a given project. |
The correspondence between engineering stages and product stages is established through the concept of product maturity level — the universal parameter at the core of the patent-pending method (Patent Pending — Ukraine). Any known waterfall estimation algorithm (COCOMO, GOST-based, ISO/IEC 15504) can be applied to modern product or Agile models through this correspondence.