-
-
Responsive Home cockpit with daily pillars, progress, Kitsu, and persistent GP.
-
Daily drill-down with totals, timing distribution, and individual intake records.
-
Log water instantly, track daily progress, and receive evidence-based insights.
-
Monthly hydration calendar with goal states, drill-down, and period insights.
-
Weekly bars, goal line, real-data summaries, and evidence-based insights.
-
Kitsu reacts to hydration progress with contextual companion feedback.
-
Water goals and reminders with per-day control and an animated goal-based water level.
-
Quick intake, custom measures, and consent-based connected insights.
KairSun — Building a Personal-Growth System with Codex and GPT-5.6
Inspiration
KairSun began with a personal problem.
I often knew what I wanted to improve, but I did not have one clear system for managing my routines, hydration, learning, limits, emotions, and long-term progress. Those parts of my life either lived in disconnected applications or were never recorded at all.
Mood was especially important to me. I noticed emotions and recurring patterns that I rarely wrote down, reviewed, or connected to my behavior. I wanted a system that could make those invisible parts of daily life easier to understand without turning self-improvement into a spreadsheet, a punishment, or another source of pressure.
That need gradually became KairSun: a local-first, gamified personal-growth application that connects daily action, reflection, learning, wellbeing, and long-term progression.
KairSun also includes the Sanctuary, a living visual representation of the user’s journey. Progress is not limited to counters and charts. Consistent actions contribute to an evolving environment designed to make growth feel personal and emotionally meaningful.
The central idea is simple:
Personal-growth tools should not only record what people do. They should help people understand themselves, recover from imperfect days, and continue moving forward.
What existed before Build Week
KairSun was already an established Flutter project before the hackathon.
It already contained multiple connected modules, a local-first architecture, a visual identity, state management, persistence, navigation, testing infrastructure, and a substantial body of product and technical documentation.
I am not claiming that the complete application was created during Build Week.
I had also used Codex extensively before July 13 on many other parts of KairSun. Those earlier sessions helped me inspect, design, debug, refactor, test, and document different areas of the project, but I deliberately excluded them from this submission because they fall outside the eligible Build Week window.
For this submission, I limited my claims to work that can be separated and verified through dated Codex sessions, branches, commits, pull requests, tests, Android builds, and repository history from the eligible period.
At submission time, KairSun contained more than 180,000 lines across application and generated code. Working inside a codebase of this size requires more than generating isolated screens. A single change can interact with Riverpod state, Drift persistence, navigation, responsive layouts, lifecycle behavior, notifications, performance rules, product economics, and privacy constraints.
The challenge was not to produce a disconnected hackathon prototype. It was to make substantial progress inside a real product without treating the existing application as disposable.
What I built during Build Week
1. A new daily cockpit for Home
I redesigned Home around one question:
What does the user need to understand and do today?
The previous experience asked Home to behave as a dashboard, a progress screen, a Sanctuary preview, and a module launcher at the same time. Too many elements competed for attention.
During Build Week, I rebuilt Home as a responsive daily cockpit:
- The four daily pillars—Water, Routine, Skills, and Mood—remain immediately recognizable.
- The message area clearly communicates what is still missing.
- The equipped companion appears without duplicating the complete Sanctuary.
- Today’s Growth Points persist across application restarts.
- Flow and streak feedback reflect real state instead of appearing active by default.
- The layout adapts to usable height, text scale, device width, safe areas, and dock geometry.
- Motion and visual effects degrade under Reduced Motion and Performance Mode.
- Dark and light modes use distinct environmental palettes.
- The selected accent color propagates through the Home experience and AppShell.
- Sanctuary progress moved into a dedicated surface with a clearer responsibility.
This work was integrated through two pull requests during Build Week.
The first Home integration changed 19 files, added 4,493 lines, and removed or refactored 3,464 lines. A subsequent AppShell and Sanctuary integration added 654 lines and removed 173 more.
The important result was not the line count. It was a clearer mental model:
Home = action and orientation
Tracking = understanding
Personalization = adaptation
Sanctuary = emotional representation of progress
2. Water became a system for action, understanding, and personalization
The largest Build Week extension was the Water module.
I did not want to build another hydration counter with a progress ring. The goal was to make hydration immediately actionable while also turning historical data into honest, useful understanding.
The new Water experience is structured around three questions:
- What should I do now?
- How have I been doing?
- How should this adapt to me?
This became:
- A daily Water surface for logging intake and understanding what remains.
- A complete Tracking experience for history, trends, exploration, and daily details.
- A Personalization experience for adapting goals, reminders, schedules, and quick-intake behavior.
The Tracking system now includes:
- Real monthly calendars with correct day offsets.
- Proportional completion states based on the goal active on each day.
- Bar and curve visualizations.
- Axes, target lines, points, and interaction.
- Daily drill-downs and bottom-sheet snapshots.
- Weekly, monthly, 30-day, 90-day, yearly, and all-time views.
- Scalable aggregation instead of rendering one widget for every historical day.
- Protection against outdated asynchronous responses.
- Progress missions when there is not enough information to support an insight.
- Animated transitions between periods and visualization modes.
- Reduced Motion and performance-aware alternatives.
The insight layer was designed around data truth.
It does not:
- Convert missing days into zero intake.
- Use future days in historical statistics.
- Treat the current incomplete day as historical evidence.
- Invent timestamps for legacy records.
- Repeat the same observation across every time range.
- Present correlations as proven causes.
- Generate cross-module insights without consent.
- Seed fake history simply to make the interface look more intelligent.
When the evidence is insufficient, KairSun says so and shows what information is still needed. It does not fabricate intelligence to make the interface appear smarter.
With consent, Water can also derive limited contextual insights from real completed events in Routine, Skills, Limits, and Detox. Each derived observation identifies its source, avoids causal claims, and is invalidated when consent is removed.
3. Personalization and Mastery without dishonest gating
I redesigned Water Personalization to support:
- One goal for every day.
- Individual goals by day.
- Global or day-specific reminder behavior.
- Reminder quantity and time ranges.
- Responsive daily-goal grids.
- A compact quick-intake configuration.
- Custom intake measures.
- Clear Free and Mastery boundaries.
- Reduced-motion and performance-aware visual behavior.
- An animated water background whose level reflects progress toward the selected goal.
I also built a controlled Mastery preview system.
A qualifying insight enters a limited preview window only when it is actually shown to the user. The system uses stable evidence fingerprints, cooldowns, time-range rotation, and protection against clock manipulation or corrupted state.
The preview never grants:
- A real subscription entitlement.
- Seeds.
- Growth Points.
- Achievements.
- Economic authority.
The user’s raw data remains accessible in Free. Mastery is intended to sell interpretation, personalization, and depth—not ownership of the user’s own information.
4. Reliable Water and Flow feedback
Water previously had several overlapping feedback systems:
- Snackbars.
- Companion popups.
- Water fullscreen celebrations.
- Generic Flow cinematics.
- Flow sheets.
- Detailed Flow screens.
This created duplication, visual noise, and the risk of presenting multiple surfaces for one event.
I consolidated them into one canonical Water celebration and one controlled transition into Flow.
The new sequence:
- Opens in the correct root navigator.
- Uses real intake records.
- Shows real timestamps only when they exist.
- Handles legacy records honestly.
- Waits for persisted Flow state before offering the transition.
- Uses single-flight guards against duplicate routes.
- Never grants rewards from presentation code.
- Replaces the previous route instead of stacking several celebrations.
- Gives Kitsu contextual reactions to progress, goal completion, and unusually large intake.
A potentially dangerous design proposal also emerged during development: allowing the user to undo the final intake after a goal had been completed.
My review identified that this could reopen a sealed goal and create opportunities to repeat achievements or rewards. The final rule prevents an edit from reducing intake below a goal that has already been completed. explains why the action is blocked, and never repeats the celebration or economic effects.
This became one of the clearest examples of how I worked with Codex: it proposed an interaction that appeared convenient, I challenged the economic risk, and the final rule became explicit, documented, and testable.
5. Real-world reliability investigation
Build Week also exposed problems that screenshots and successful builds could not reveal.
In one case, device logs traced a blocked onboarding flow to a partially applied Drift migration. I investigated the real SQLite schema and implemented a local recovery approach that made the affected migration path idempotent.
Those additional onboarding and v11 recovery edits were preserved in a separate local checkout. They are not part of the final judging snapshot, so I am not presenting them as submitted functionality.
The reliability work that did reach main through PR #36 includes Water ledger and migration tests, sync race guards, startup defenses, notification privacy, and release safeguards.
This investigation reinforced a lesson that mattered throughout Build Week:
A successful build does not prove that the application works.
Runtime evidence, device logs, and the exact submitted snapshot have to remain authoritative.
How I built it with Codex and GPT-5.6
I used Codex with GPT-5.6 in high-reasoning mode as my primary engineering collaborator throughout Build Week.
Codex helped me:
- Inspect unfamiliar and highly connected areas of the repository.
- Reconstruct context across a large, evolving codebase.
- Trace Riverpod providers, state ownership, and side effects.
- Understand Drift tables, migrations, and persistence behavior.
- Implement and refactor Flutter components.
- Diagnose lifecycle, navigation, layout, and asynchronous-state failures.
- Run parallel red-team inspections.
- Build targeted regression tests.
- Review diffs for accidental scope expansion.
- Compile Android builds.
- Inspect device logs.
- Install updates without deleting existing user data.
- Update feature contracts and bug history.
- Reconcile implementation claims with Git, tests, and runtime evidence.
I also used Claude Code and Antigravity for selected parallel reviews and integration tasks. Their use is disclosed, but the Build Week submission and its primary implementation evidence center on Codex and GPT-5.6.
As noted above, I had already done much more work with Codex before July 13. I intentionally excluded that earlier work from the Build Week claim, even when it was relevant to the product, because I wanted the submission to distinguish clearly between KairSun’s prior history and the extension completed during the eligible period.
The key was not only choosing a capable model. I also had to give Codex clear boundaries, relevant context, and evidence it could not ignore.
KairSun’s repository includes:
AGENTS.md
A repository-level contract describing universal boundaries around architecture, data, economy, privacy, testing, and Git operations.
Context routing
The agent loads the smallest relevant context pack for the current feature instead of reading unrelated documentation or guessing the architecture.
Specialized skills
Different risks activate different procedures:
- Forensic inspection.
- Drift migration safety.
- Riverpod state review.
- UI and glassmorphism quality.
- Performance and motion auditing.
- Runtime Android QA.
- Privacy and security review.
- Monetization and economy gates.
- Scope locking and branch isolation.
- Documentation-status honesty.
Feature contracts
Product decisions become explicit invariants, such as:
- Missing data is not zero.
- Legacy events do not receive invented times.
- Raw user data remains accessible.
- A completed goal is sealed against economic replay.
- Celebrations do not grant rewards.
- A normal phone must not fall into an emergency compact layout.
- Reduced Motion and Performance Mode must be respected.
Bug history and living documentation
Each important failure records:
- The symptom.
- The real cause.
- The correction.
- The regression gate.
This allows another agent to continue the work without relying on an enormous prompt or informal memory.
Human gates
Codex does not receive final authority over:
- Expanding scope into sensitive systems.
- Mutating cloud infrastructure.
- Merging pull requests.
- Declaring incomplete validation successful.
- Changing product economics.
- Presenting uncertain claims as facts.
This system did not magically prevent every mistake.
There were weak first iterations, layout overflows, inert controls, lifecycle crashes, contradictory state, a Water Tracking design that initially failed its purpose, and an APK that compiled but did not run correctly.
What mattered was that these failures could be reproduced, challenged, corrected, and documented instead of being hidden behind a successful build.
Evidence from the Build Week extension
| Area | Evidence |
|---|---|
| Home | PR #33 merged during Build Week; 19 files; +4,493 / −3,464 |
| AppShell and Sanctuary | PR #34 merged; +654 / −173 |
| Water | Work began July 17; PR #38 merged July 21; 44 files; +7,102 / −1,972 |
| Water validation | 75 focused tests passed; focused analysis clean; git diff --check passed |
| Android | DEV APK compiled and installed on a Motorola Edge 30 Fusion while preserving data |
| Reliability | PR #36 merged reliability/security/sync hardening; additional onboarding recovery remained outside the judging snapshot |
| Agent collaboration | Dated Codex sessions, commits, branches, feature contracts, bug history, and runtime evidence |
The Water work was merged into main through PR #38. Its original branch and commits remain preserved as dated implementation evidence.
The main challenges
Designing depth without cognitive overload
A personal-growth application can become exhausting if every useful metric becomes another card, tab, filter, or chart.
The final direction was:
Simple by default. Deep when needed.
Every surface needed to answer a specific question rather than merely display more information.
Preserving truth while generating insights
It is easy to make an application appear intelligent by inventing certainty.
It is much harder to represent missing data, incomplete periods, changing goals, legacy limitations, consent, and uncertainty honestly.
I chose the harder path.
Safely changing a mature codebase
A local visual correction could affect persistence, navigation, lifecycle, notifications, analytics, performance, or product economics.
Codex was valuable because it could trace those connections before editing, but the repository’s rules were necessary to prevent broad, attractive, and unsafe changes.
Knowing when to remove a feature
During Water development, I investigated weather-aware hydration, commercial API constraints, location privacy, caching, and offline location data.
The feature was technically possible, but it added permissions, visual height, privacy complexity, and product noise without enough immediate value.
I removed it.
One of the most useful outcomes of an AI-assisted workflow is not building everything faster. It is evaluating more possibilities and rejecting the wrong ones earlier.
What I learned
Build Week reinforced several lessons:
- Product quality comes from stronger relationships between features, not from feature count.
- Responsive behavior is part of product design, not final-stage cleanup.
- Historical data is valuable only when its interpretation is honest.
- A premium system should sell clarity and adaptation, not hold user data hostage.
- A successful build is not a successful runtime.
- AI agents perform better when scope, evidence, and authority are explicit.
- The agent must be allowed to surface uncertainty instead of being rewarded for confident completion.
- Generated code is increasingly accessible; coherent product judgment remains difficult.
- Human review is especially important around privacy, economics, emotional design, and unintended incentives.
- Documentation becomes far more valuable when it functions as executable context for future agents.
What comes next
KairSun currently derives its new insights through deterministic, privacy-conscious rules.
My next major direction is an optional AI intelligence layer using the OpenAI API.
With explicit user consent, transparent data selection, and strict privacy controls, an AI layer could help users:
- Connect patterns across hydration, routine, mood, skills, and limits.
- Receive weekly summaries grounded in their real history.
- Understand which behaviors are associated with their strongest and weakest days.
- Generate realistic next steps.
- Adapt goals during demanding periods.
- Recover from setbacks without abandoning the complete system.
- Build personalized learning and improvement roadmaps.
The goal is not to place a generic chatbot inside KairSun.
The goal is to create a contextual intelligence layer that turns personal data into clear, honest, and actionable guidance.
KairSun is a serious product that I intend to launch and continue developing beyond Build Week.
This hackathon did not create its entire history.
For me, Build Week demonstrated how far a real product can move when Codex and GPT-5.6 accelerate the engineering work, while human judgment still decides the product direction, the boundaries, and what is actually ready to ship.
Log in or sign up for Devpost to join the conversation.