< cd ~/raba.pl

Developer & personal tools

Lifecycle Tracker

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
Lifecycle Tracker interface

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

  1. StageEach product sits in one stage, from Ideation to Exit, shown on the Stage Rail.
  2. QuestionsThe stage's wizard asks what that stage needs answered, filtered by sub-stage.
  3. ChecklistSub-stage tasks, with custom items per stage and completion tracking.
  4. MetricsIntegrations pull revenue, usage and delivery numbers into time series.
  5. 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

Technology

  • Next.js
  • tRPC
  • Zod
  • PostgreSQL
  • Drizzle ORM
  • Better Auth
  • Claude API

Explore another problem I worked on

>_ Your next project

Liked what you saw?
Let’s get in touch!

Have an idea, a challenge, or a role in mind? I’d love to hear about it.

Let’s talk

>_ Start a conversation

Liked what you saw?
Let’s get in touch!

Tell me what you’re working on. Let’s see how I can help.

Email mepatryk@raba.pl
Send a message