Supportive AI chat
2024 · Archived learning project
Fathership
Turning an open chat box into one steady, practical next step
I built Fathership while learning full-stack development: an account-based Rails chat companion designed to respond with empathy, a concrete action, and clear limits when the model is unavailable or the conversation becomes high risk.
Quick scan
TL;DR
The shortest version: what changed, what shipped, what was verified, and where the proof stops.
Overview
Problem
A generic assistant can answer a question without making someone feel heard or giving them a manageable next move.
Move
Framed each response around reflection, one action for the next 24 hours, and a gentle follow-up—then carried that contract through the chat interface and fallback states.
Outcome
Completed and later modernized an archived Rails learning project with authenticated conversation history, optional OpenAI responses, local fallbacks, resource pages, and checked-in regression tests.
Scope
Independent product concept, visual design, Rails implementation, AI integration, and a 2026 reliability and deployment refresh.
Proof
- Build history
- 23 commitsRepository history spans July 14, 2024 through February 20, 2026.
- Regression surface
- 12 test casesChecked-in model and controller tests cover chat behavior and the primary routes.
- Context boundary
- 8 recent turnsThe default model request excludes older conversation turns to bound cost and context.
- Operating mode
- AI optionalThe product returns local supportive responses when an OpenAI token is absent or a request fails.
01 · Context
The first challenge was shaping a useful kind of support.
Fathership began as an early full-stack project around a simple idea: make a calm, father-figure style of conversation easier to reach. The application was not intended to replace professional support; it was a way to explore whether tone, continuity, and practical advice could make a chat interaction feel more grounded.
That product question created a useful engineering one. The experience needed accounts, private conversation ownership, persistent history, model integration, and a clear path through failure—not just a prompt connected to an API.
02 · The decision
Give the assistant a response contract, not only a personality.
Reflect what was heard. Offer one practical step. Ask one useful question.
The current system prompt turns a broad persona into a repeatable interaction pattern. Responses should be concise and plain-spoken, prefer concrete examples, and help the person do something within the next 24 hours. Medical, legal, and financial risk is redirected toward professional support.
The same principle appears in the interface. Prompt starters reduce blank-state friction, the composer shows an explicit character limit, and the pending state tells the person what the system is doing instead of leaving the interaction inert.
Engineering noteFailure is handled as part of the conversation.
OpenAI access is optional. The chat model bounds input and context, retries transient errors, and returns local supportive responses when the external service is missing or unavailable.
- Messages are limited to 700 characters by default and model context is limited to the latest eight turns.
- The API path uses configurable timeouts, token limits, and bounded retries.
- A local crisis-keyword branch surfaces U.S. 988 and emergency guidance instead of attempting a normal generated response.
03 · What shipped
A small but complete account-to-conversation loop.
Devise handles registration, sign-in, profile, and account recovery. Each chat belongs to a user, and controller lookups are scoped through the signed-in user before conversations can be shown, updated, or deleted.
Inside the chat, Turbo Streams update the conversation and chat list while a Stimulus controller handles enter-to-send, autosizing, character counts, optimistic pending messages, recovery after failed requests, and scroll position. A separate resource library connects the conversational experience to practical external material.
Make the exchange legible
Engineering noteConversation ownership lives in the query boundary.
Authorization is enforced by loading chats through the authenticated user instead of retrieving a global record and checking it afterward.
- All chat routes require an authenticated user.
- Create uses current_user.chats.new; show, update, and destroy use current_user.chats.find.
- Deleting a user cascades to that user’s stored chats.
04 · Evidence
The evidence is a maintained learning artifact, not market validation.
The repository records 23 commits from July 2024 through February 2026. The original build established the Rails product; the later refresh reduced old surface area, rebuilt the chat interaction, added bounded AI configuration and local fallbacks, tightened account-scoped access, and prepared a low-cost PostgreSQL deployment path.
The checked-in suite contains 12 model and controller test cases, including conversation persistence, message limits, chat creation and deletion, and the core content routes. Those tests were inspected as source evidence for this case study but were not rerun while the sibling repository remained read-only.
No reliable usage, revenue, retention, or outcome analytics were found. The claims here are limited to repository history, implemented behavior, test coverage present in source, and archived product captures.
05 · Reflection
The useful lesson was learning where a prompt stops and a product begins.
The early version focused on the visible conversation. Revisiting it later made the surrounding system more important: ownership, loading and error feedback, context limits, recoverable failure, resource handoffs, and deployment constraints all shape whether the exchange earns trust.
The project also exposed the difference between aspiration and proof. Early landing-page copy implied an audience the repository could not substantiate. Archiving Fathership as a learning project—and describing only the behavior that can be inspected—is a more accurate account of what it achieved.
A future version would require a deeper safety model, expert review, privacy documentation, and behavioral research before making stronger claims about emotional support outcomes.