01/
What the product does today
Actual current behavior, not the original spec or what documentation claims.
Product Modernisation & Improvement
Structured improvement for an existing product and its constraints.
Start with the current state
Modernise the product when several constraints need
one transition plan
A rebuild is not the default. We compare the requirement against a bounded feature, a design-only redesign, and an infrastructure-only change first.
TIER01
Bounded feature addition
TIER02
Design-only redesign
TIER03
Infrastructure-only change
TIER04
Coordinated modernisation
Current and target state
Understand what the product does today—and what
depends on it
Change is only safe once the current state, its dependents, and its non-negotiables are actually known.
02/
What depends on it
Users, integrations, and operational processes that would break if this changed carelessly.
03/
Why change is needed now
The specific limitation — user, technical, or operational — driving the request.
04/
What must keep working
The behavior that cannot regress during the transition, named explicitly.
Strategy per boundary
Choose a strategy for
each product boundary
Retain, repair, refactor, replatform, replace, or retire are decisions made area by area, not a single verdict on the whole product.
(001)
Choose a strategy per boundary, not one word for the whole system
Retain, repair, refactor, replatform, replace, or retire are decisions made area by area, not a single verdict on the whole product.
(002)
A rebuild is one option, not the default
Most inherited problems are addressable without discarding what already works.
(003)
Data and integration migration gets its own plan
Ownership, validation, coexistence, and rollback are designed before any cutover.
(004)
Change ships in reviewable stages
Each stage protects operational continuity and produces evidence before the next begins.
Technology decisions
Modernisation &
migration stack
The stack follows the requirement, not the other way round. These are the categories this engagement typically has to decide.
01
Next.js & React
02
TypeScript
03
Microservices & Docker
04
PostgreSQL & Prisma
05
API Gateways
06
Automated Migration Scripts
Possible scope
Plan the transition around data and dependencies, not
only new code
The exact scope depends on the current state and target. None of the following should be assumed automatically.
Current-state mapping across product and technical boundariesDependency and constraint recordTarget-state and success-evidence definitionNon-goals and explicit exclusions
Retain, repair, refactor, replatform, replace, or retire per boundaryData and integration migration planSequencing and coexistence planRollback and validation criteria
Staged product and technical changesData migration and reconciliationIntegration updatesRegression protection for critical behavior
Before/after evidence for the changeRelease and rollout recordDocumentation of the resulting stateOngoing coverage decision
Modernisation decisions
Change the architecture only where the product and
operation justify it
Every modernisation decision trades something specific for something else. The useful choice is the one whose reason is understood.
01
Rebuild or transition in place?
Staged change usually preserves more value and reduces risk; a rewrite is justified only when the evidence supports it.
02
Switch all at once or run both systems in parallel?
Coexistence costs more upfront but catches problems before they reach every user at once.
03
Does the architecture actually need to change?
Architecture change is justified by real constraints and target behavior, not framework fashion.
04
Patch the symptom or address the cause?
A narrow fix can be the right call when the underlying structure is not actually the constraint.
Inspectable outputs
See the starting state, the intervention, and
the resulting product
Deliverables should make the transition and its evidence visible and testable.
01/
Current and target state record
What exists, what should change, and what must keep working.
02/
Strategy decisions per boundary
The retain, repair, refactor, replatform, replace, or retire choice for each area, with reasoning.
03/
Migrated and validated system
The implemented change with data and integration validation evidence.
04/
Before/after evidence
Baseline, intervention, and resulting state, in a form that can be checked, not just claimed.
Delivery and engagement
Use a bounded transition before
deciding what continues
The starting engagement should establish evidence before any change is scoped.
01
BOUNDED DISCOVERY
Current-state assessment
A bounded review of the existing product to establish evidence before any change is scoped.
02
FIXED-SCOPE MILESTONE
Defined modernisation transition
A project-shaped engagement for one staged, bounded change.
03
STAGED RELEASES
Phased transition
Several dependent boundaries modernised in sequence, each validated before the next.
04
CONTINUOUS CADENCE
Ongoing product engineering
Continued responsibility once modernisation moves into an active roadmap.
Fit and routing
Use Modernisation when the transition crosses product
and technical boundaries
Product Modernisation is the right starting point for a coordinated transition. A different service may own a narrower need.
01/ ALTERNATIVE
Custom Software Development
Choose this when the need is a genuinely new system, not a transition of an existing one.
02/ ALTERNATIVE
UI/UX Product Design
Choose this when the change is design-only and implementation is not in scope.
03/ ALTERNATIVE
Cloud & DevOps
Choose this when the problem is entirely infrastructure, not the product itself.
04/ ALTERNATIVE
Ongoing Product Engineering
Choose this when the need is continuing roadmap responsibility, not a bounded transition.
Frequently Asked Questions
Product Modernisation & Improvement questions,
answered clearly.
Technical delivery and architecture details. Key decisions regarding code quality, integrations, and handoff rituals.
No. A rebuild is one option among retaining, repairing, refactoring, replatforming, replacing, or retiring specific boundaries. The evidence and product risk should determine the strategy.