standup.

Most productivity tools focus on task management: lists, checkboxes, due dates. But I wanted something different: a tool that captures intent vs. reality across days and uses that delta to surface behavioral patterns.

The concept is simple. Every morning, you write what you plan to do. Every evening, you write what actually happened. Over time, the gap between those two entries reveals your real patterns: recurring blockers, energy cycles, follow-through tendencies. Things you can't see in a single day but that become obvious across weeks.

The core requirements:

The system is a decoupled monorepo: a Rails API backend and a React SPA frontend, communicating over a typed REST API with JWT auth and automatic timezone synchronization on every request.

The backend is a Rails 8.1 API-only app with no views and no asset pipeline. The frontend is a Vite-powered React 19 SPA with TypeScript. They're fully decoupled: the frontend sends X-Timezone on every request so the server always knows the user's local “today,” and JWT tokens are stored in localStorage. The AI layer is a single service class that talks to OpenAI's chat completions API via raw Net::HTTP. No SDK, no background jobs, no queues.

The check-in system is the core of the app. It enforces a simple but strict contract: one morning check-in and one evening reflection per calendar day per user.

Rather than separate models for morning and evening entries, I used a single checkins table with an enum. This was the key design decision. It keeps queries simple and lets the database enforce the business rule:

The composite unique index on [user_id, date, checkin_type] enforces “one morning, one evening per day” at the database level, not just in application validation. Conditional presence validators (today_plan required for mornings, what_happened required for evenings) mean each check-in type collects the right fields without separate models or STI.

One of the trickiest parts of a daily check-in app is answering: “What day is it?” If the user is in Tokyo and the server is in UTC, “today” is a different date. I solved this by auto-syncing the user's timezone on every authenticated request:

The frontend detects the browser's IANA timezone via Intl.DateTimeFormat and attaches it as an X-Timezone header on every API call. update_column intentionally skips validations and callbacks. This is a high-frequency, low-risk write; the timezone just silently stays in sync.

A single today endpoint returns both morning and evening check-ins for the user's current local date. The frontend uses this to determine which cards are filled, which are waiting for input, and whether to show the “day complete” state.

The AI layer is built as a single service class (AiService) that handles three distinct operations: post-check-in nudges, daily summaries, and weekly digests. All use OpenAI's GPT-4o-mini via raw HTTP. No SDK, no abstractions.

The nudge is the most user-facing AI feature. After each check-in, the frontend fires a request to generate a one-sentence observation based on the user's recent history:

Key design decisions: the nudge requires at least 3 recent check-ins before activating, since pattern-matching on a single data point is not useful. The prompt explicitly instructs the model to find non-obvious patterns and avoid echoing what the user just wrote:

The nudge is best-effort. If OpenAI fails, parsing fails, or there's not enough history, it silently returns nil and the frontend just doesn't show anything.

Daily summaries take a morning/evening pair and produce a structured coach diagnosis. The prompt asks for a specific JSON contract, and the output is formatted into a four-part framework:

Every field has a sensible fallback, so even if the model returns a partial or malformed response, the user always sees actionable output.

Weekly digests aggregate a full week of check-ins plus daily summaries into a narrative recap. The prompt packs each day's morning/evening data, feelings, and AI insights into a structured format, then asks for wins, patterns, and blocker analysis.

The critical design decision: the controller computes server-side metrics independently of the AI response.

Average energy and completion rate are calculated from raw check-in data, not from the model's output. The AI provides narrative analysis, but the hard metrics are computed deterministically. You never want the model deciding what your completion rate is.

The dashboard gives users an at-a-glance view of their accountability data through four bento-style stat cards and two time-series visualizations.

Streak calculation loads all distinct check-in dates in a single query, then walks backwards from today in Ruby:

This avoids N+1 queries. One pluck fetches up to 365 dates as an array, then the streak is a linear O(n) walk. The 365-day window caps the query scope without limiting realistic streak lengths.

“Follow-through” is the percentage of mornings that also have a matching evening reflection on the same date. It's the core accountability metric. It answers “when you set an intention, did you close the loop?”

The query uses a subquery to find mornings whose dates also appear in the evenings set. This runs as a single SQL query, not two separate fetches.

Feeling data is aggregated per-day and rendered as a Recharts area chart with a gradient fill. Below it, a heatmap shows ternary completion state: none, partial (morning only), or complete (both check-ins). The backend computes all of this in just two queries: group(:date).average(:feeling) for mood data and group(:date, :checkin_type).count for completion flags, then builds the daily array in Ruby.

The main Today page uses a 3D card flip interaction for morning and evening check-ins. Each card has a front face (a tilted image card with a daily prompt) and a back face (the check-in form or completed entry).

Framer Motion's layoutId enables a seamless animation from the signed-out state (where the cards float at angles as peek previews) to the signed-in state (where they become full interactive panels). Daily prompts rotate based on the day index for variety without randomness.

The mood selector uses a custom 7-point glyph system where each level has a hand-drawn SVG icon (raindrop for “drained,” flame for “energized,” sun for “great”) instead of a numeric slider. People relate to visual metaphors better than numbers on a scale.

History uses a horizontal scroll layout where today is leftmost and you scroll right into the past. As you scroll, the container uses elementFromPoint to detect which month the viewport center is in, and a floating month overlay fades in (“March 2026”) then auto-hides after 1.8 seconds of no change. The entire 90-day range loads in a single API call to avoid pagination complexity.

The app uses a layered visual stack for atmosphere. All components are custom, built without any component library:

Authentication uses a minimal JWT implementation: no sessions, no cookies, no refresh tokens. Tokens expire after 7 days, stored in localStorage and sent as a Bearer header. On 401 responses, the API client automatically clears the token and forces re-auth.

Pages like History, Dashboard, and Weekly show a LockedOverlay when the user isn't authenticated: a blurred preview with a sign-in prompt rather than a redirect. The Today page is always accessible, showing a marketing-style welcome state with tilted peek cards.

Weekly digests have a shareable public endpoint that requires no authentication. The share URL uses a unique token per digest (not per user), and intentionally omits blocker_patterns. Wins and patterns are shareable, but blockers are private. Only the user's name is exposed, no email or other account data.

The schema is designed around the daily check-in lifecycle with four tables:

Every unique constraint is enforced at the database level, not just in Rails validations. All foreign keys are explicit. Text fields are validated to 2000 characters max. The schema evolved iteratively. Early versions used a single body field; structured fields were added in a later migration while keeping body nullable for backward compatibility.

The backend uses a production-ready multi-stage Dockerfile with jemalloc for memory optimization. The entrypoint runs db:prepare before starting the server, handling both initial setup and migrations on deploy. The frontend builds to a static Vite bundle with CORS configured via environment variable.

The AI layer degrades gracefully when OPENAI_API_KEY is absent. AiService.chat returns a static JSON fallback string so all downstream parsers still receive valid JSON. The app is fully functional without AI; the features just show placeholder content.

Concept to deployed product in 36 hours of focused solo work.

The most useful decision was modeling check-ins as morning/evening pairs in a single table. One enum, one composite index. That one choice made everything downstream trivial: streaks, follow-through, AI prompts that compare what you planned to what actually happened.

The other thing I didn't expect: the visual polish ended up being load-bearing. WebGL shaders, physics-based card tilts, custom SVG mood glyphs. For a tool you're supposed to open every morning and every evening, the aesthetic is what turns it from a form into a ritual.

The main gap right now is that the app relies on you remembering to check in. Adding push notifications for morning/evening reminders would close that loop. Beyond that, wrapping the SPA as a PWA for home screen installation is the obvious next step for a daily-use tool.