Command: cat projects/leadership-cockpit.md
A leadership cockpit for a product and technology director
A personal prototype that turns the scope of a product and technology director role into a management tool: the mandate and KPIs with targets, the decisions only that role can unblock, the systems inventory, a Scrum board, a leadership guide, meeting scripts, a proposal generator and a presentation builder. It is a tool for my own use, with the data kept in the browser.
open the demoa simulation of the system with fictional data · 5 screens
- Role
- Design and development, for my own use
- Period
- Jul 2026 – Jul 2026
- What I did
Me: The design of the role (mandate, KPIs with targets, a three-phase sprint cycle and a leadership guide) and the whole prototype, from the interface to the state kept in the browser.
Private project, described without identifying the client, product or company.
Diagram
The Next.js app brings together the cockpit with KPIs and decisions, the team with the leadership guide, the personal sprint, the pipeline with proposals, the meeting scripts and the slide deck. All of them keep their state in a Zustand store, rehydrated after the page mounts and persisted in localStorage: the sprint, the KPIs, the decisions and the deck. There is no data server: no account, no API and no database.
Context
As product and technology director of a business group, the scope of the role lived in a document: roadmap, architecture, security and data protection, leading teams, integrating systems, and KPIs such as uptime and lead time. I wanted it to become the routine of the week.
What I built
- Cockpit. The role’s mandate, a three-phase sprint cycle (organization, execution and closing), KPIs with target, current value and status, the decisions only the role can unblock, the systems inventory and the technical priorities.
- Team and org chart. Each person with role, area, mandate, KPI and channel, and a leadership guide: how to lead, how to explain the role and what to delegate.
- Personal sprint. An editable five-column Scrum board, saved in the browser.
- Pipeline and proposals. The opportunities with the technical angle of each one, and a generator that assembles the proposal text from a catalog.
- Meetings and presentations. Step-by-step meeting scripts in full screen and a deck builder with five slide types and a presentation mode.
- A command palette with global search, and its own navigation on phones.
What I would do differently
It is a prototype for my own use, with no automated tests and the data in a single browser. If it became a tool for more people, the first step would be a backend with accounts and permissions, and the second, tests for the KPI rules and for the saved state.
Constraints
- A tool for my own use, with no server for the data.
- The role's targets next to the measured value, and "no data" when nothing is measured.
- Usable on desktop and phone, with global search on a keyboard shortcut.
Decisions
State in the browser, with controlled rehydration
- Context
- A personal tool needs no account and no database, but state kept in the browser can disagree with what the server rendered on the first load.
- Choice
- State persisted in localStorage for the sprint, the KPI values, the resolved decisions and the deck, with controlled rehydration after the page mounts.
- Gains
- No management data on a server, and no account to create.
- The first render and the saved state never conflict.
- Costs
- The data lives in a single browser, with no sync across devices, and is gone if the browser is cleared.
The role's targets as data, not as text
- Context
- The formal scope of the role listed targets such as 99.9% uptime, a fast response to critical support, patches within 48 hours and monitored daily backups, as plain text.
- Choice
- Each KPI has a target, a current value, a unit, a direction (higher or lower is better) and a status: ok, attention, critical or no data. Each pending decision has a priority and a category.
- Gains
- The weekly review becomes updating numbers in one place.
- Costs
- Values are typed by hand; nothing is measured automatically.
Upgrading the framework on the day of a CVE
- Context
- The framework version in use had a published vulnerability.
- Choice
- Move to the next major version of the framework the same day, instead of waiting for the prototype to mature.
- Gains
- The prototype never lived with a known vulnerability.
- Costs
- A major upgrade in the middle of the build, with changes to check.
Stack and why
- Next.js 16 and React 19
- Interface and routes; upgraded from version 15 to 16 to fix a CVE.
- TypeScript
- Types for people, KPIs, decisions, tasks, opportunities and slides.
- Zustand
- State persisted in the browser with controlled rehydration.
- Tailwind and Framer Motion
- Cards, a command palette and entrance animations.
Results
not verified
Security angle
Attack surface
- Management data kept in the browser.
- Proposal text built from free-form fields and copied to the clipboard.
Controls in place
- No data sent to a server, with no account, API or database.
- The framework upgraded on the same day a CVE was published.
What I would test today
- Malicious content pasted into the deck and proposal fields.
- Behavior with the browser's storage full or corrupted.
Evidence
- audited private repositoryAudited private repository(Audit of the private repository, Sep 2026)