1,300 messages across 220 sessions (440 total) | 2026-02-09 to 2026-02-24
At a Glance
What's working: You've built an impressive full-stack application from a vanilla JS prototype all the way to a production multi-tenant Fresh/Deno app with SSR, WebSockets, bot detection, and multi-locale support — effectively using Claude as both architect and implementer. Your tight iterative refinement cycle is a real strength: you ship features, then immediately polish colors, fix localization strings, and tune playback behavior in focused follow-up sessions, which keeps your product moving forward consistently. Impressive Things You Did →
What's hindering you: On Claude's side, initial implementations frequently land with type errors, lint violations, and logic bugs that require two or three fix passes — and fixes sometimes introduce secondary bugs (like CSS changes breaking font loading or client bundles pulling in server-only modules). On your side, queuing three or four features per session means you regularly hit rate limits with work left at the planning stage, and Claude sometimes burns session budget exploring wrong files or approaches before you step in to redirect. Where Things Go Wrong →
Quick wins to try: Set up a hook to auto-run `deno fmt` and `deno check` after every file edit — this would catch the type errors and lint issues that are your single biggest source of friction before they compound. Also consider creating a custom `/deploy` skill that bundles your pre-deploy checks, change verification, and release notes generation into one command, since you're already doing this manually. Features to Try →
Ambitious workflows: As models get more capable, you'll be able to spawn parallel agents — one for the backend route, one for the Preact island, one for CSS — all working off a shared interface contract, which should dramatically reduce the sequential implement-then-discover-bugs pattern. Even more impactful for your multi-tenant setup: an autonomous rollout pipeline that implements a feature once, then systematically generates translations, adapts per-tenant configs, and validates SEO metadata across all your locales, eliminating the recurring pattern where things work for one tenant but break for others. On the Horizon →
The core project is a multi-tenant route mapping web application built with Deno Fresh, TypeScript, and MapLibre, featuring animated route playback, multi-stop routing, landmark notifications, road trip selectors, and country-specific landing pages. Claude Code was used extensively for feature implementation across the full stack—building island components, server-side rendering, geocoding caches, and iterative UI refinements. Sessions typically involved multi-file changes with several rounds of bug fixing for type errors, lint issues, and browser-specific quirks.
SEO, Localization & Multi-Tenant Configuration~15 sessions
Significant effort went into SEO-friendly prerendered routes, sitemap generation, country-specific landing pages with location permutations, Finnish/Swedish/Norwegian localization, and multi-tenant architecture with per-tenant configs (e.g., tightHeader, noindex directives). Claude Code handled cross-cutting changes across routing, templates, and configuration files, though SEO landing page implementations required multiple attempts due to build errors from mixing server/client code and approach pivots.
Work included building admin CRUD interfaces for all database tables, migrating from Postgres to SQLite, implementing live visitor dashboards with WebSocket updates, bot detection/scoring analytics, buffer status tickers, and active user counts. Claude Code was used to scaffold admin UIs, write migration scripts, and implement real-time features across backend APIs and frontend components, with most sessions achieving their goals and passing tests.
UI Styling & Visual Polish~12 sessions
Numerous sessions focused on visual refinements including Finnish road-sign-themed styling, authentic fonts, mobile-responsive layouts, dark orange button palettes, CSS variable management, road sign banner components, and color adjustments. Claude Code made targeted CSS and component edits efficiently, though one road sign banner implementation was fully reverted by the user, and Safari-specific rendering bugs required follow-up debugging.
Production Debugging & Deployment~8 sessions
Sessions addressed production issues including broken visitor count displays, CSP violations, AdSense errors, service worker bugs, CSS loading failures in production builds, route playback zoom creep, and JS bundle optimization via lazy-loading MapLibre. Claude Code excelled at diagnosing root causes—such as DOM ordering issues and per-frame animation conflicts—and applying surgical fixes, with deploy script documentation and pre-deploy risk identification also handled.
What You Wanted
Feature Implementation
37
Bug Fix
23
Feature Addition
7
Ui Styling
5
Ui Styling Change
5
Ui Feature Addition
5
Top Tools Used
Read
2626
Edit
2079
Bash
1413
Grep
1378
TaskUpdate
607
TaskCreate
322
Languages
TypeScript
3875
CSS
419
Markdown
242
JavaScript
191
Shell
86
HTML
45
Session Types
Single Task
35
Multi Task
27
Iterative Refinement
20
Exploration
1
Quick Question
1
How You Use Claude Code
You are a prolific, feature-driven builder who drives Claude through ambitious multi-feature sessions at a relentless pace. Across 220 sessions in just two weeks, you consistently pack 3-4 sequential feature requests per session, treating each conversation as a mini sprint — for example, asking for multi-tenant architecture, geocoding caching, popularity tracking, and a landing page redesign all in one sitting. You clearly have a strong mental model of your architecture (a multi-tenant Fresh/Deno routing app with MapLibre, SQLite, and localization for Nordic markets) and you issue directives with confidence, expecting Claude to keep up. When Claude drifts — like when it started exploring the wrong approach for geocoding caching or began acting before you finished giving routing backend requirements — you interrupt quickly and redirect, showing low tolerance for wasted cycles.
Your interaction style is best described as iterative refinement under pressure. You don't write detailed upfront specs; instead, you fire off a request, let Claude implement it, then immediately course-correct when bugs or design mismatches surface. This is evident in sessions where landmark proximity notifications needed repositioning, route landing pages required three separate attempts with different approaches, and CSS/font fixes cascaded through multiple rounds. Your friction data tells the story: 28 instances of buggy code and 24 wrong-approach issues were the dominant pain points, yet you maintained high satisfaction (144 likely satisfied out of 180 rated sessions) because you're comfortable with this fast-feedback loop. You treat Claude as a high-throughput implementation engine rather than a careful architect.
Notably, you heavily leverage Claude's sub-task system (607 TaskUpdates, 322 TaskCreates, 240 Tasks) and lean into multi-file changes (49 successful instances), suggesting you trust Claude with large-scoped refactors across your TypeScript codebase. However, you commit remarkably rarely — only 2 commits across 220 sessions — indicating you review and batch changes yourself outside of Claude. When Claude gets stuck in excessive planning or research (as happened during the Fresh migration and bot detection sessions), you cut the session short without hesitation. Your pattern is clear: ship features fast, fix bugs in-session, and move on.
Key pattern: You run high-velocity, multi-feature sessions where you rapidly fire requests, interrupt when Claude drifts, and iterate through bugs in real-time rather than specifying upfront — treating Claude as a fast implementation engine you steer with constant course corrections.
User Response Time Distribution
2-10s
64
10-30s
106
30s-1m
121
1-2m
146
2-5m
126
5-15m
134
>15m
165
Median: 114.8s • Average: 468.9s
Multi-Clauding (Parallel Sessions)
142
Overlap Events
139
Sessions Involved
27%
Of Messages
You run multiple Claude Code sessions simultaneously. Multi-clauding is detected when sessions
overlap in time, suggesting parallel workflows.
User Messages by Time of Day
Morning (6-12)
508
Afternoon (12-18)
361
Evening (18-24)
363
Night (0-6)
68
Tool Errors Encountered
Command Failed
211
Other
115
User Rejected
74
File Changed
36
File Too Large
15
File Not Found
11
Impressive Things You Did
You've been intensively building a multi-tenant, multilingual route mapping application over two weeks, with 220 sessions showing a deeply iterative and ambitious development approach.
Massive Multi-File Feature Development
Your most dominant success pattern is coordinating complex changes across many files simultaneously — 49 sessions featured successful multi-file changes spanning TypeScript, CSS, and configuration. You're building out entire features like multi-tenancy, geocoding caching, landmark systems, and admin CRUD interfaces in single sessions, treating Claude as a full-stack implementation partner rather than a snippet generator.
Rapid Iterative Refinement Cycles
You have a highly effective pattern of shipping features and then immediately refining them — adjusting road sign colors, tweaking mobile layouts, fixing localization strings, and tuning playback behavior in focused follow-up sessions. This tight feedback loop means you're consistently moving from 'mostly achieved' to polished production quality, and your 144 likely-satisfied sessions reflect how well this workflow serves you.
Full-Stack Architecture From Scratch
You've orchestrated an impressive technical journey from a vanilla JS map prototype through Deno/Hono, then Fresh v2 with Preact, adding SQLite, multi-tenancy, SSR for SEO, WebSocket live updates, bot detection, and production hardening with CSP and deploy scripts. You're effectively using Claude as an architect and implementer to build a sophisticated production application with proper infrastructure concerns like service workers, analytics, and noindex directives for fallback tenants.
What Helped Most (Claude's Capabilities)
Multi-file Changes
49
Correct Code Edits
14
Good Debugging
9
Good Explanations
2
Proactive Help
2
Outcomes
Not Achieved
8
Partially Achieved
11
Mostly Achieved
28
Fully Achieved
37
Where Things Go Wrong
Your sessions are consistently productive but are undermined by buggy first-pass implementations, rate limit interruptions cutting work short, and Claude occasionally going down wrong paths before you correct it.
Your feature implementations frequently ship with type errors, lint violations, missing props, and logic bugs that require two or three additional fix passes before checks pass. You could reduce this churn by asking Claude to run deno check and lint after every implementation before moving on, or by breaking large multi-file changes into smaller verified steps.
The landmark proximity feature initially inserted landmarks before the final destination instead of the next waypoint, and the notification was mispositioned — requiring multiple correction rounds before the logic and UI were right
The country-specific route pages had several bugs after initial implementation (non-city locations listed, missing glyphs config crashing the map, broken Nominatim suggestions, landmark refresh failures) that demanded extensive back-and-forth debugging
Rate Limits and Session Timeouts Cutting Work Short
You frequently hit rate limits or session boundaries right when Claude is partway through a task, leaving features at the planning stage or with unfinished fixes. You could mitigate this by front-loading your highest-priority task in each session and explicitly telling Claude to implement before planning additional features, rather than queuing three or four features that inevitably get cut off.
Your Deno Fresh porting session was immediately blocked by a rate limit, accomplishing zero work on the request you came in with
The multi-tenancy architecture session hit usage limits after the landmark groups task was interrupted, leaving only a written plan with no code delivered for either feature
Claude Exploring Wrong Approaches Before You Redirect
Claude sometimes spends significant time researching, fetching docs, or exploring the wrong files before you intervene, wasting your session budget. You could prevent this by providing more upfront context in your initial prompt — specifying exact files, the approach you want, and explicitly saying 'don't research, just implement.'
When you asked for a simple Deno backend, Claude spent so long exploring the codebase that you interrupted and exited before anything was created
The Fresh framework migration session saw Claude stuck in an extended research/planning phase with excessive web fetches, never starting actual code changes before you had to interrupt
Primary Friction Types
Buggy Code
28
Wrong Approach
24
Rate Limit Interruption
8
Misunderstood Request
6
Rate Limit
5
Excessive Changes
2
Inferred Satisfaction (model-estimated)
Frustrated
5
Dissatisfied
12
Likely Satisfied
144
Satisfied
4
Existing CC Features to Try
Suggested CLAUDE.md Additions
Just copy this into Claude Code to add it to your CLAUDE.md.
Across many sessions, type errors, formatting issues, and lint violations repeatedly surfaced after implementation, requiring multiple fix rounds — this was the single most common friction pattern.
Multiple sessions hit build errors from bundling server-only modules into client code or using incompatible Fresh v2 patterns (e.g., dynamic _app.tsx titles), wasting significant debugging time.
A recurring pattern was Claude planning or starting a second feature while the first still had bugs, leading to sessions ending with multiple incomplete features instead of fewer solid ones.
At least two sessions had bugs where English text appeared instead of localized text because translation calls were missed, and tenant-specific config was forgotten.
Multiple sessions had friction where Claude started coding before the user finished explaining (e.g., routing backend request repeated 3 times, geocoding caching wrong approach), wasting time on wrong implementations.
Multiple sessions failed because Claude spent excessive time on web fetches and research without writing any code, leading to user interruptions and abandoned sessions.
Just copy this into Claude Code and it'll set it up for you.
Hooks
Auto-run deno fmt and deno check after every file edit
Why for you: Your #1 friction source is type errors and formatting issues surfacing after implementation. Hooks can catch these instantly on every edit, eliminating the multi-round fix cycles that plagued 20+ sessions.
Create a /deploy skill that runs pre-deploy checks, verifies changes since last tag, and generates release notes
Why for you: You have a multi-tenant Fresh app with complex deploy requirements — one session was dedicated entirely to deploy script docs and pre-deploy risk checks. A /deploy skill codifies this workflow so it's consistent every time.
# Create .claude/skills/deploy/SKILL.md with:
## Deploy Checklist
1. Run `deno check` on all modified files
2. Run `deno test` to verify all tests pass
3. Check `git diff` since last tag for risky changes
4. Verify all tenant configs are valid
5. Check for hardcoded English strings (should use i18n)
6. Verify no node:-prefixed imports in island/ files
7. Generate a summary of changes for release notes
Headless Mode
Run automated lint/type/format checks on changed files before committing
Why for you: With only 2 commits across 220 sessions, you're doing a lot of work but rarely committing. A headless pre-commit check could validate everything automatically, giving you confidence to commit more frequently.
# Add as a git pre-commit hook or run manually:
claude -p "Check all files modified since last commit. Run deno fmt --check, deno check, and deno lint on each. Report any issues found and fix them." --allowedTools "Read,Edit,Bash,Grep"
New Ways to Use Claude Code
Just copy this into Claude Code and it'll walk you through it.
Sessions frequently end with incomplete second features
Scope sessions to one major feature at a time instead of chaining 3-4 features.
A strong pattern in your data: sessions request 3-4 features sequentially, the first 1-2 get fully implemented, but the last one only reaches 'planning stage' before the session ends due to rate limits or context exhaustion. This happened in at least 12 sessions. You'd get better completion rates by breaking large feature lists into focused single-feature sessions, each starting with a clear, complete specification.
Paste into Claude Code:
I want to implement ONE feature this session: [describe feature]. Here are the complete requirements: [list all requirements]. Do not plan any other features. Focus entirely on implementing this, running all checks, and ensuring it works before we finish.
Buggy code is your top friction — request test-first implementation
Ask Claude to write a failing test before implementing features to catch bugs earlier.
28 sessions had 'buggy_code' friction and 24 had 'wrong_approach' — these are your two biggest pain points. Many bugs (missing glyphs config, wrong waypoint insertion order, client/server module mixing) could have been caught with upfront tests. Asking Claude to write a test first forces it to think through edge cases before coding, and gives an immediate verification mechanism.
Paste into Claude Code:
Before implementing this feature, write a test that verifies the expected behavior. Then implement the feature and make the test pass. Finally run deno check and deno fmt.
Rate limits are killing productivity — use Task agents for exploration
Use sub-agents for codebase exploration instead of spending main session context on it.
You hit rate limits in 19+ sessions (combined rate_limit variants), and several sessions failed because Claude spent too long exploring the codebase or fetching docs before writing code. Task agents (which you already use heavily — 322 TaskCreate calls) can handle exploration in parallel, preserving your main session's context budget for actual implementation. Be explicit about delegating exploration to sub-agents.
Paste into Claude Code:
Use a task agent to explore the current codebase structure for [feature area] and report back with: 1) relevant files, 2) existing patterns to follow, 3) potential gotchas. Then implement the feature based on those findings.
On the Horizon
Your 220 sessions reveal a power user building a sophisticated multi-tenant routing app, where the biggest gains now lie in eliminating the iterative fix cycles that consume most of your Claude Code time.
Parallel Agents for Multi-File Feature Implementation
Your data shows 49 successful multi-file changes but 28 instances of buggy code and 24 wrong-approach friction events — most from Claude implementing sequentially and discovering issues late. By spawning parallel sub-agents via TaskCreate (you already use 322 task creations), you could have one agent handle the backend route/API, another the Preact island component, and a third the CSS/styling, all converging on a shared interface contract. This would cut your average feature implementation time dramatically while catching integration issues at the boundary rather than after full implementation.
Getting started: Use Claude Code's built-in task orchestration (TaskCreate/Task) to define parallel workstreams with explicit interface contracts between them, then have a coordinator agent merge and run deno check.
Paste into Claude Code:
I need to implement [FEATURE] across my Fresh v2 multi-tenant app. Break this into parallel sub-tasks: (1) Backend/API layer — define the route handler, database queries, and types in a shared interface file first, (2) Frontend island component — build the Preact component against that interface with proper TypeScript types, (3) CSS/styling — implement responsive styles following our existing Finnish road-sign design system. For each sub-task, create a Task. Each task must: write its code, then run `deno check` and `deno lint` independently. After all three complete, integrate them together and run the full check suite. If any check fails, fix it before proceeding. Do NOT move to the next integration step until all checks pass.
Test-Driven Bug Fix Loop with Auto-Validation
You have 23 bug fix sessions and 28 buggy-code friction events, with issues like CSS breaking font loading, client/server code boundary violations (node:sqlite in client bundles), and Safari-specific rendering bugs. Instead of the current diagnose-fix-check-fix cycle that often takes multiple rounds, Claude can autonomously write a failing test that reproduces the bug first, then iterate its fix against that test until it passes — eliminating the pattern where fixes introduce secondary bugs. Your 2 commits across 220 sessions suggests most work stays uncommitted, meaning an autonomous test-fix-commit loop would also improve your deployment velocity.
Getting started: Structure bug reports as test-first prompts and let Claude Code iterate in a Bash loop running deno test until green, then auto-commit with a conventional commit message.
Paste into Claude Code:
Bug report: [DESCRIBE BUG AND HOW TO REPRODUCE]. Fix this using test-driven development: (1) First, write a test that reproduces this exact bug — run it and confirm it FAILS. (2) Then iteratively fix the source code, running `deno test` after each change. Do not stop until the new test passes AND all existing tests still pass. (3) Also run `deno check` and `deno lint` to ensure no type errors or lint violations. (4) If your fix introduces any new test failures, fix those too before proceeding. (5) Once everything is green, run `git add -A && git commit -m 'fix: [concise description]'`. Show me the test output at each step so I can see the progression from red to green.
Autonomous Multi-Tenant Feature Rollout Pipeline
Your app serves multiple tenants (Finnish, Swedish, Norwegian locales) and you repeatedly hit friction from missing translations, tenant-specific config oversights (like the tightHeader fix), and locale-specific bugs. An autonomous pipeline could implement a feature once, then systematically roll it across all tenants — generating translations, adapting configs, testing each tenant's routes, and validating SEO metadata (noindex directives, sitemaps, localized slugs). This eliminates the pattern where features work for one locale but break or are incomplete for others, which your session data shows happening repeatedly.
Getting started: Use Claude Code to build a tenant validation checklist that runs as a Bash script after every feature, checking translations, route generation, meta tags, and tenant-specific rendering for each configured domain.
Paste into Claude Code:
I just implemented [FEATURE] for one tenant. Now roll it out across all tenants in our multi-tenant Fresh app. For each tenant/locale configured in the codebase: (1) Grep for all user-facing strings added in this feature and ensure translations exist for every locale — if missing, add natural-sounding translations (Finnish, Swedish, Norwegian). (2) Check that any new route handlers work for each tenant's domain configuration. (3) Verify tenant-specific config (tightHeader, noindex settings, color themes) still applies correctly. (4) Run `deno check` and `deno lint`. (5) For each tenant, use Bash to curl the relevant dev server routes and verify they return 200 with correct lang attributes and meta tags. (6) Create a summary table showing: tenant | feature status | translations complete | routes verified | issues found. Fix any issues you find before presenting the summary.
"Claude built a road sign banner component, passed all checks — and the user immediately reverted everything"
During a session on the Finnish route mapping app, Claude fully implemented a mobile road sign banner UI component. The code was done, checks passed… and the user instantly asked to revert all changes, suggesting the end result just wasn't what they had in mind. A perfect 'thanks but no thanks' moment.