Skip to content

Generated file. Source: docs/product_roadmap.en.md Edit the source document and run npm run docs:sync to refresh this published copy.

Product Roadmap

PM -> Developer / Stakeholder Document

  • product: Treasury Bond Calculator
  • document class: authoritative product roadmap
  • document status: active
  • version: 1.0
  • last review: 2026-03-23
  • document owner: Product Manager
  • document goal: maintain a single source of truth for the order of product development stages, their dependencies, priorities, and scope

1. Role of This Document

This document is the authoritative source of truth for the product roadmap.

This means:

  • the order of stages should be defined here
  • any change to stage priority should be defined here
  • any change to stage scope should be defined here
  • the roadmap shown in the UI should be a derived presentation of this document

This document does not replace the product specification.

Relationship between documents:

  • product_spec.en.md defines the product, its current scope, and the decisions currently in force
  • this document defines the sequencing and purpose of future development stages
  • bond_engine_architecture.md describes the technical architecture supporting current and future development

2. Roadmap Maintenance Rules

  • update this document first
  • then update the roadmap section in the specification if the change alters product meaning or dependencies
  • finally update the UI roadmap in NextStepsPage.tsx: src/app/components/NextStepsPage.tsx
  • if the UI roadmap and this document diverge, this document is the source of truth
  • each stage should have a clear goal, scope, business value, and entry criteria for the next stage

3. Primary Assumption

The roadmap is meant to guide the product from a comparison calculator toward a tool that, in later iterations, can support an investment bond portfolio project: historical, continuously updated, and based on data from specific bond issues.

Key planning principles:

  • first close business logic and UI rules for the MVP
  • then automate data and build auditability
  • next extend the inflation model and scenario layer
  • only then move into more complex investing cases and account types
  • the calculator input assistant should come only once the form model and recurring-investment logic are already stable

4. Stage Dependencies

flowchart LR
    P0[Stage 0\nFinalize MVP logic] --> P1[Stage 1\nData automation]
    P1 --> P2[Stage 2\nDatabase and saved simulations]
    P2 --> P3[Stage 3\nInflation model]
    P3 --> P4[Stage 4\nMin/max scenarios]
    P3 --> P5[Stage 5\nVolatility simulator]
    P2 --> P6[Stage 6\nRecurring investing and IKE/IKZE]
    P3 --> P6
    P4 --> P6
    P5 --> P6
    P6 --> P7[Stage 7\nInput assistant]

Interpretation:

  • Stage 0 closes product and interpretation decisions
  • Stage 1 builds trustworthy automated input data
  • Stage 2 builds the data foundation for the future portfolio and saved simulations
  • Stage 3 should build on the foundation from Stage 2 and feed the same data layer with inflation predictions and their history
  • Stage 4 and Stage 5 are optional extensions after Stage 3, not a mandatory linear chain
  • Stage 6 may begin once the data layer and the core simulation model are stable, but it should also be able to use the results of Stage 4 and Stage 5 if they are implemented earlier
  • Stage 7 relies on a mature form and must not create its own calculation logic

5. Roadmap Stages

5.1 Stage 0. Finalize Business Logic and UI for the MVP

Priority: Highest

Goal:

  • define and freeze product rules before data automation and further roadmap expansion begin

Business value:

  • reduces the risk of building additional features on top of unresolved business decisions
  • allows the current calculator to be treated as a consciously defined MVP entry point

Scope:

  • describe the current calculation model and verify behavior for each bond type
  • define reinvestment rules, especially for long horizons and different bond families
  • define simulation and data-presentation scenarios for bonds with different interest payout mechanics, capitalization rules, costs, and taxes
  • decide whether the product should primarily show the real investment state at the end of each year according to each product’s settlement logic, or a unified comparison model
  • decide whether and when the user should be able to switch between presentation scenarios, for example the real path and a “what if I end the investment in year X” comparison view
  • clearly distinguish that the default yearly results primarily show the investment path, while a separate “end the investment in each subsequent year” scenario is introduced as an explicit interpretation model rather than a hidden MVP semantic
  • define how taxes, costs, and result interpretation should be shown in the UI
  • explicitly document items postponed beyond the MVP, including the 800+ purchase amount cap and IKE / IKZE logic

Success criteria:

  • a closed description of business requirements exists for the current calculator
  • data-presentation and result-interpretation rules are consistent between logic and UI
  • decisions postponed beyond the MVP are explicitly documented and do not get mixed into the current product scope

5.2 Stage 1. Automation of Market and Issuance Data

Priority: Highest

Goal:

  • reduce manual maintenance of input parameters and build a trustworthy data source for further product development

Business value:

  • increases trust in the calculator
  • shortens data update time
  • creates the foundation for future portfolio features

Scope:

  • automatic retrieval of the current NBP reference rate
  • automatic retrieval of current inflation as the default input parameter
  • build a scraper to fetch issuance terms and update the bond catalog
  • validate data in the pipeline and safely publish changes to the catalog

Success criteria:

  • the reference rate and current inflation no longer need manual updates
  • new issues and term changes can be updated without editing application logic
  • catalog changes have history and are auditable

5.3 Stage 2. Database Foundation for the Future Bond Portfolio

Priority: High

Goal:

  • extend the scraper and data model from a simple issue catalog into the beginning of a database that will support a future investment portfolio product and user-saved simulations

Business value:

  • opens the path to showing historical issues, portfolio history, saved calculations, and current investment state without rebuilding the whole product from scratch

Scope:

  • collect data about specific issues, not only bond types
  • build issue-parameter history so the investment state can be reconstructed over time
  • prepare a data model that can later store: purchase date, issue series, historical parameters, saved calculation, and current portfolio state
  • prepare the data layer to store inflation predictions, their source, fetch date, and later comparison with actual inflation

Success criteria:

  • the application has a ready data model for historical issues
  • the user can return to a saved calculation or simulation
  • the historical context of a specific purchase can be shown in the future portfolio
  • the current investment state can later be updated without losing historical data
  • the data layer is ready to store and version inflation predictions

5.4 Stage 3. Expansion of the Inflation Model

Priority: High

Goal:

  • move from a single manually entered inflation value to a more realistic predictive model

Business value:

  • the user gets a result closer to real market expectations instead of a single simplified scenario

Scope:

  • extend the simulation mechanism with inflation prediction fetched from an external source
  • separate manual inflation from default or fetched inflation
  • save the inflation prediction used in the simulation, together with its source, version, and fetch date, into the data layer prepared in Stage 2
  • prepare the ability to compare a past prediction with later actual inflation
  • prepare UX that clearly shows which source supplied the prediction used

Success criteria:

  • the user can use a default prediction without manually entering inflation
  • the engine can work with inflation data coming from outside the form
  • the prediction used in a simulation can be saved and reconstructed later
  • the product can later show how an inflation prediction diverged from reality

5.5 Stage 4. Min / Max Scenarios and Result Range

Priority: Medium

Goal:

  • extend a single simulation into scenarios that show not one outcome, but a range of possible outcomes

Business value:

  • the product becomes more decision-useful because the user sees not only the base result, but also its sensitivity to inflation

Scope:

  • add minimum and maximum scenarios for a given inflation range
  • allow comparison of the base result with the extreme results
  • adjust charts and tables so they show both the point result and the range

Success criteria:

  • the user sees at least three results: base, minimum, and maximum
  • the UI clearly distinguishes the central result from the scenario spread

5.6 Stage 5. Inflation Volatility Simulator

Priority: Low

Goal:

  • add a more advanced scenario model that accounts for historical inflation volatility within the adopted prediction range

Business value:

  • this moves the product from a simple calculator toward an analytical tool showing more realistic investment uncertainty

Scope:

  • create a simulator of inflation paths within the accepted prediction range
  • use historical volatility as the basis for building scenario deviations
  • prepare a way to present results as a range or distribution, not a single number

Success criteria:

  • the engine can generate many inflation paths for the same investment
  • the user sees not only an extreme result, but also a distribution of possible outcomes

5.7 Stage 6. Recurring Investing and IKE / IKZE

Priority: High

Goal:

  • extend the calculator from a one-time investment model to a recurring-investment model that also accounts for account type

Business value:

  • the product becomes closer to real investor behavior and can support regular bond portfolio building

Scope:

  • add the option to invest in bonds regularly, for example monthly or yearly
  • add the option to calculate investments through IKE or IKZE
  • extend the engine with the impact of account type and contribution schedule on the final result

Success criteria:

  • the user can compare one-time and recurring investment
  • the final result changes depending on the contribution schedule and selected account type

5.8 Stage 7. Calculator Input Assistant

Priority: Medium

Goal:

  • allow the user to prepare a complete simulation through dialogue instead of manual form completion

Business value:

  • lowers the barrier to entry for less technical users
  • shortens the path from entry to the first meaningful result
  • increases product usefulness without creating a separate calculation engine

Scope:

  • a start question asking whether the user wants to use the assistant
  • a sequence of questions about investment parameters, such as starting amount, recurring contributions, contribution frequency, investment horizon, 800+, and account type
  • support both one-time and recurring investment situations
  • map answers to the same form state used by the manual mode
  • run the same simulation and the same engine as the manual calculator
  • allow the user to switch to manual form editing after the dialogue ends

Success criteria:

  • the user can reach a complete simulation without manually filling in every field
  • the result produced through the assistant is identical to the result for the same data entered manually
  • the assistant does not create separate financial logic, it only feeds the existing form and engine
  • the user can switch to manual mode after the dialogue without losing data

6. Rule for Updating the UI Roadmap

The roadmap screen in the application:

  • should reflect the stages from this document
  • may simplify language for user-facing communication
  • should not independently change stage order, priorities, or scope

If the UI roadmap and this document stop matching:

  1. update this document if the product decision changed
  2. update the UI if only presentation changed or the UI fell behind

7. Related Documents