In-house product tools
I build in-house tools similar to Jira and Confluence, shaped around the product team’s work.
SELECTED WORK / PRODUCT · QUALITY · BUILDING
A closer look at the work.
The problem, my contribution and the decisions behind the output.
01 / HANGİKREDİ / AI TRANSFORMATION
AI transformation for the entire product team.
The problem
AI transformation extends beyond introducing a tool. Product work also needs systems for planning, documentation, ideas, productivity and day-to-day AI use.
My contribution
As an AI Product Owner at HangiKredi, I lead AI transformation across the product team. I build the tools and systems that make the team’s work easier, and support adoption through AI use and training.
WHAT I BUILD & ENABLE
Five connected areas of work.
Project management dashboard
I build a dashboard to make project management more visible and easier to follow.
Productivity workflows
I build tools and workflows aimed at reducing repetitive work and making the team’s daily work easier.
Ideas & contribution to value
I work on systems that support idea generation, suggestions and turning contributions into product value.
AI adoption & training
I support the team’s use of AI through training and by bringing AI tools into everyday product work.
The starting point is the team’s need. I build the internal product that helps address it, rather than limiting the work to one type of tool.
PUBLIC WALKTHROUGH / REPRESENTATIVE CONTENT
One example: from a need to a backlog.
This habit-tracking example demonstrates the method. It is not an internal HangiKredi document or a company performance result.
INPUT / BEFORE GENERATION
“I want to keep a weekly reading goal.”
Clarify the unit, week boundary and completion rule. A polished sentence is not yet a complete requirement.
- Unit: pages
- Period: local calendar week
- Goal: user-defined
STRUCTURE / PRODUCT DEFINITION
Define the behaviour before the interface.
- Scope
- Create a weekly page goal, log reading and display progress.
- Decisions
- The week follows the local calendar; an entry can be corrected.
- Out of scope
- Social competitions and purchase flows.
REVIEW / TESTABLE BEHAVIOUR
Make the edge cases part of acceptance.
- A saved reading entry updates weekly progress once.
- Correcting an entry recalculates the total.
- The week boundary uses the agreed local calendar rule.
- A failed save does not display a successful completion.
OUTPUT / REVIEWABLE WORK ITEMS
Split by behaviour, with tests attached.
DEMO-01Weekly goal setupValidation & persistenceDEMO-02Reading log & progressSave, edit, recalculateDEMO-03Calendar boundary testsLocal date & week transitionHuman review: scope, product intent, priorities and generated work items.
What this changes
In this workflow, PRD, analysis and backlog become parts of one reviewable product story. It is one example of the wider transformation work, alongside internal tools, dashboards, productivity and training.
02 / LUMIAN LABS / HABITARIAN
A small detail. A real product consequence.
- Independent product
- Product & quality practice
- Source-based case
The product
Through Lumian Labs, I build Habitarian: habit tracking, consistency, XP and social challenges. My work connects product concept, experience design, premium journeys and release preparation.
The decision: whose “today”?
A UTC date and the device’s local calendar date can be different. If completion feedback uses one and streaks use the other, the same action can belong to two different days.
The documented change
The project’s completion/streak review records a shared local-date helper being used across completion feedback, app-open streaks, retention milestones and insight ranges.
That is a consistency rule across the experience, not just a formatting change.
EXPLORE THE EDGE CASE / CALCULATED IN YOUR BROWSER
Same moment. Different calendar dates.
User’s local date2026-05-04
Date from UTC conversion2026-05-03
The example illustrates the documented date-boundary issue. It does not connect to a user account or production data.
Completion should count once.
The same review documents two existing protections: a client-side in-flight guard and a database condition preventing XP from being awarded twice. The review separates behaviour that needed changing from behaviour already protected.
The outcome
The documented correction brings the affected flows onto the same local-day rule. Completion feedback, streaks and insights can refer to the same calendar day.
03 / QUALITY & RELEASE
A release needs more than a green check.
My practice
My product work includes acceptance-criteria validation, QA/UAT coordination, issue tracking and release readiness. At ICRON, I also worked on test strategy, performance testing and release management.
The useful output
A release decision that shows what has been checked, what remains uncertain and who owns the next action. An automated check is not a substitute for a real-device or business-acceptance check.
What was checked?
Scope, environment and critical user journeys.
What remains open?
Known issues, product risk and explicit owners.
When do we stop?
Release conditions, follow-up and rollback questions.
A useful next conversation