Make the next decision visible when several products are moving at different speeds.
internal
Documented February 2026
Solo: product, code
The problem
Separate tools track code, revenue, research and tasks, but they do not necessarily explain what matters at the current stage. The design needed to connect that information to the next decision.
My part
My internal product workspace, presented here through its documented design.
What this shows
I can structure an ambiguous operational problem and make the decisions, dependencies and evidence explicit.
Where it started
Lifecycle Tracker is an internal product workspace. It organizes products from ideation through launch, growth and exit, with questions and criteria for each stage.
See it in action
Product walkthrough · 0:40 · 60 FPS · English narration
English AI narration · Subtitles included · Play with sound, or read the transcript.
Read the video transcript
0:00 Lifecycle Tracker explores a structured way to manage several products at once.
0:07 Each product moves through the same stages, from the first idea to launch and beyond.
0:14 Questions, checklists and metrics make the next decision explicit before a stage is passed.
0:20 The product workspace brings those decisions and tasks together.
0:27 The design separates product data keys from the master key, making rotation more manageable.
0:34 This is an unreleased project. These diagrams explain its documented design.
The decisions behind the product
Use stages to organize the work
The documented design gives every product a stage, a set of questions, a checklist and criteria for moving forward. A shared rail shows where the portfolio stands.
Put evidence beside decisions
The product workspace groups research, metrics, integrations and context around the current stage, rather than leaving them in separate product-wide tools.
Design a consistent integration boundary
The case study describes a shared pull-and-push adapter for integrations and time-series metrics, alongside a per-product secrets vault.
What came out of the work
A documented operating model
The case study defines an eleven-stage product track and a common place for questions, tasks, evidence and graduation criteria.
An internal design, shown as such
The project is not publicly released. The demo uses diagrams to explain the product stages, the evidence behind decisions and the integration boundaries.
Inside the implementation
Explore the features, architecture and quality checks
What I built
A stage framework every product follows: Ideation, Validation, Planning, Design, Development, Alpha, Beta, Launch, Growth, Maturity and Exit
Per stage: wizard questions, a sub-stage checklist with custom items, and graduation criteria for moving on
A Stage Rail that shows where every product stands
A workspace per product with tabs for the wizard, checklist, marketing, integrations, metrics, secrets, research and context
Integrations behind one adapter with pull() and push() methods, mapped onto metrics so they fill in automatically
Metrics as time series by category: financial (MRR, ARR, churn), growth (DAU, MAU) and development (DORA)
A secrets vault with AES-256-GCM envelope encryption, per product and per user
Claude API features: a product brief drafted from the wizard answers, and marketing copy
Research documents with tags and sources, attached to stages
How it works
StageEach product sits in one stage, from Ideation to Exit, shown on the Stage Rail.
QuestionsThe stage's wizard asks what that stage needs answered, filtered by sub-stage.
ChecklistSub-stage tasks, with custom items per stage and completion tracking.
MetricsIntegrations pull revenue, usage and delivery numbers into time series.
GateGraduation criteria decide when the product moves on to the next stage.
Quality and reliability
Secrets use envelope encryption: each product's data key is wrapped by a master key, so rotating the master key re-wraps keys instead of re-encrypting every secret
Every integration implements the same adapter, with pull() and push() methods
Known limit: not publicly released, so the video shows diagrams of the documented design instead of the app
Known limit: the source was not available for this page, so it follows the project's case study and shows no code metrics