Theory: An Engineering Method to Control Software Delivery Dates
Estimation is not guessing. It is an engineering verification calculation.
In classical engineering (aviation, construction, heavy industry), an experienced professor can validate in minutes what took weeks to compute. The trick is not magic and not "marketing" — it is a verification model: simplified, but physically correct, ignoring secondary details while preserving the core mechanics.
Digital Polygraph applies the same "professor's view" to software projects. We do not scan your backlog, tickets, or user stories. We look at the physics of your project: the functional spectrum, the complexity of the environment, the architectural role, the innovation risk, and the reuse level. This produces an engineering-grounded effort estimate (person-days) before you write the first line of code.
Note: the underlying methodology is described in an invention application. This page is a practical guide to the ideas, not a legal text.
1. The Core Idea: A Bridge Between Engineering and Product
Modern software teams often track how they work (sprints, velocity, throughput), while business leaders need what the market receives and when it arrives (deadlines, budgets, market windows). Agile can describe team speed. Business needs a predicted arrival date — and a clear definition of "ready".
The method introduces Product Maturity Level as a universal parameter that connects: (1) strict engineering stages (planning precision), and (2) business-friendly product artifacts (market reality).
Translation Map: Engineering Stages ↔ Product Milestones
This is a practical translation map — designed for clarity and management, not academic formalism.
| Engineering stage | Abbr. | Product artifact | Meaning (maturity) |
|---|---|---|---|
| Technical Assignment | TA | Discovery | Requirements maturity. Goals, boundaries, constraints, and success metrics are defined. |
| Preliminary Design | PP | Prototype | Concept maturity. Key risks are tested; hypotheses are validated; not yet "production code". |
| Technical Design | TP | MVP | Technical MVP maturity. Architecture is approved; the core scenario works end-to-end. |
| Working Design | WP | Release Candidate | Full engineering maturity. Feature-complete, tested, documented, deployment-ready. |
| Techno-Working Design (combined) | TWP | RC (Combined) | Combined implementation path. TP and WP are merged into one continuous stream to reach RC without a formal MVP stop. |
| Implementation | IM | Production | Operational maturity. Running in the real environment (Live), supported, delivering value. |
Note: Total is an integral result that adapts to the selected life cycle (Choice): skipped stages are excluded, and merged stages (e.g., TWP) are accounted for accordingly.
2. The "Time Machine" Effect: Turn Effort Into a Release Date
Why "Time Machine"? Because it flips the planning question.
Instead of: "We have 5 developers — when will we finish?"
You can ask: "We need a market artifact by a fixed date — how many people do we need, and where?"
The control lever: adjusting team size on specific stages shifts Prototype, MVP, and Production dates transparently. You manage time-to-market by managing resources, not by hoping.
3. Project Hologram: Three Coordinated Axes
Axis 1: Functional Spectrum — What are we building?
Like spectral analysis in physics, the project is decomposed into a measurable signature. Functions (Step 2) plus a full complexity spectrum (Steps 3–6) define the project "mass" — its effort in person-days — independent of language and framework fashion.
The calculator applies a spectral analysis to your project, decomposing it into measurable parameters. From this spectrum, it assembles a volumetric model — a project "hologram" — that replaces intuition with an explainable structure.
Axis 2: Life Cycle Design — Which path do we choose?
You select a strategy (Choice): do you need a Prototype? a formal MVP? a combined implementation stream (TWP)? This is life cycle design — not "skipping work".
Axis 3: Time & Resources — When do we arrive?
Once effort and life cycle are known, team sizing becomes a management instrument. Step 7 turns effort into a calendar trajectory by distributing developers across stages under a defined fund.
In our terminology: Cyclos describes the development rhythm (the selected stages), Kairos describes readiness moments (Discovery, Prototype, MVP, RC, Production), and Chronos turns effort into calendar time through team sizing.
4. Strategic Choice: Four Life Cycle Strategies
The calculator offers four baseline strategies. To make the logic instantly visible, each choice is shown as a "spliced chain": engineering stage + product artifact in one line.
Choice #1 — Maximum Control
TA(Discovery) → PP(Prototype) → TP(MVP) → WP(Release Candidate) → IM(Production)
Best for high-risk systems and regulated domains where each maturity step must be explicitly verified.
Choice #2 — No Separate Prototype
TA(Discovery) → TP(MVP) → WP(Release Candidate) → IM(Production)
When the concept is clear, but a formal MVP and a controlled path to RC are still required.
Choice #3 — Combined Path to Release Candidate
TA(Discovery) → PP(Prototype) → TWP(Release Candidate) → IM(Production)
Common for startups: validate the idea via Prototype, then run a continuous stream to RC without a formal MVP stop.
Choice #4 — Fast Track
TA(Discovery) → TWP(Release Candidate) → IM(Production)
For internal tools and low-risk solutions where speed dominates and the combined stream is acceptable.
Note: TWP is not "less work". It is an intentional merge of TP and WP to support time-to-market planning by avoiding a formal intermediate MVP stop.
5. For Investors: Capital Is a Function of Time
Investors and founders are not buying "lines of code". They are financing time until a market artifact exists. Delays increase burn and can destroy a market window. The goal is not to promise success — it is to reduce uncontrolled uncertainty.
- Maturity stages make readiness explicit and reduce rework risk.
- Effort in person-days supports earlier budget planning (before implementation locks you in).
- Team sizing as a lever helps align a roadmap with financing and milestones (Seed, Series A, partner commitments).
This is a mechanism of control, not a marketing guarantee: you see where the project is vulnerable and you can adjust the plan early.
6. How to Read the Result
Treat the output as a future map, not a single magic number. Pay attention to:
- how effort is distributed across stages,
- where the "bottlenecks" are within the chosen life cycle,
- how sensitive the delivery date is to team changes on specific stages.
Compare scenarios by changing only one factor at a time (life cycle strategy, reuse level, innovation risk, team distribution).
Example Scenario
You have a fixed market window (for example, a launch tied to a conference in 6 months). Start with a conservative life cycle (e.g., Choice #2). If the total duration exceeds the deadline, try a more direct life cycle (e.g., Choice #4). If it is still too long, increase team size on the critical stage (often TWP or WP). If budget is constrained, accept a later date or reduce scope.
7. Before You Start: A Short Checklist
- Do you understand the product goal, constraints, and the target market window?
- Did you choose the life cycle strategy consciously (not "because it looks shorter")?
- Did you rate innovation realistically (avoid inflating it "just in case")?
- Did you rate reuse honestly (standard software, frameworks, platforms, configurable components)?
- Do you know which artifact you must have first (Prototype vs MVP vs RC) and why?
Start Planning Like an Engineer
Stop guessing. Start designing your delivery trajectory.
Define the functional spectrum, choose the life cycle strategy, and allocate resources so your plan meets reality at the right time.
Summary: this page is pre-flight guidance. The calculator performs the computation. The output is your project's future map.