My first hackathon project and an experiment in interaction design.
It began as a simple Halloween diary but quickly turned into a small digital world that pushed my understanding of UI behaviour and UX constraints. The goal quickly shifted from 'a themed diary' to building an interface that responds to the user- the app reacts when you move, when you stop, when you write, when you switch tabs, when you try to leave, and some of the environment comes alive after inactivity.
This post explains the architecture, the trade-offs, the mistakes and how Kiro influenced the engineering process.
Behavioural System
The core idea was that the UI should respond to behaviour: tab switching triggers short status messages, cursor inactivity causes certain components to animate or shift, extended inactivity prompts environmental changes, focused sections reduce visual noise, among others.
These features rely on lightweight, event-driven state machines and tightly controlled side effects. The aim was to maintain predictability even as the behavioural layer became more involved.
Architecture and Stack
React with TypeScript
TailwindCSS
Firebase for authentication and Firestore
Vite
Internal state machines for behaviour decisions
Custom animation hooks
Utility modules to isolate logic
Throughout development, most of the work went into preventing the behavioural features from overwhelming the render cycle. The hardest part was deciding which components should respond to user inputs and which should remain static. Too much activity creates noise and too little undermines the concept for the costume contest.
Working With Kiro
Documentation
The project kept its evolving specifications inside the .kiro folder, including the Haunted Diary spec, scrapbook flow diagrams, interaction rules, and trigger definitions. This mattered because the direction changed rapidly and documentation acted as a reference point.
Refactoring and Code Quality
This was the single most significant contribution. Kiro repeatedly refactored components, reorganized structure, removed redundant logic, and improved readability. It prevented the project from drifting into an unmanageable architecture.
Testing
Kiro wrote, refined, and expanded test suites. It identified edge cases early and ensured behavioural triggers did not contradict each other.
Performance
The first version of the project struggled with render timing. Kiro helped identify unnecessary rerenders, reorganized several components, and improved lazy loading strategies to maintain smooth interaction.
Error Handling and Compliance
It added guardrails, mapped error states, and guided compliance for user content.
Tooling and Micro-Interactions
Some of the small UX touches emerged from working with Kiro: tooltips, animation timing, message tone, and micro-responses that make the environment feel cohesive.
Challenges
The project was ambitious for a first hackathon submission: state confusion occurred because multiple versions of certain components existed. The sensory balance problem required deliberate tuning.
Behavioural triggers occasionally competed with one another, and improving their priority logic took time.
This project became an exploration of animated UX and demonstrated how Kiro contributes to proper engineering practices- it contributed to documentation, refactoring, testing, performance tuning, and architectural decisions. For a first hackathon submission and working alone, the workflow felt closer to a real engineering process than a rushed weekend build (I know, that you know what it feels like).
Top comments (0)