I needed a task manager that thought the way I do.
I have ADHD, which means task management isn't optional — it's how I stay functional. I'd tried every app I could find. None of them worked the way my brain works: too simple, too complex, or organized around teams and collaboration when I just needed to manage my own work as a freelancer.
I was also a longtime user of Workflowy — a minimalist, keyboard-navigable outline tool — and I wanted that same interaction model applied to actual project management. The infinite nesting, the focus mode, the keyboard-first navigation. Applied to real work.
I also had a practical need: my job at the time required tracking how much time I spent on individual tasks. I wanted that built into the same tool I was already using, not as a separate app.
The original version launched in 2016 under the name projectr, as a tool I built entirely for myself. What exists today — Tilled — is a complete rewrite, built with a decade of additional perspective and a different ambition: software worth putting in front of other people.
Keyboard-first task management for the way solo work actually flows.
Tilled organizes work in a flexible hierarchy — areas, projects, tasks, and subtasks that can nest as deeply as the work requires. The hierarchy maps to how freelance and solo work is actually structured, without imposing artificial limits on how you think about it.
The task list is keyboard-navigable in the style of an outline editor — create, nest, reorder, complete, and navigate without touching the mouse. Focus mode lets you zoom into any subtree, isolating just the work that's relevant right now. Time tracking is built directly into individual tasks: start a timer when you begin work, stop it when you're done, and accumulated time rolls up to the project level.
Tilled installs as a PWA on desktop and mobile. No app store required.
The design philosophy behind every decision is documented in the philosophy page. The ADHD-specific design principles that informed those decisions are developed in depth in a white paper I wrote and published: The Interface as Prosthetic: UX Design Principles for Productivity Software in ADHD.
Built as craft software — intentionally, not incidentally.
The rewrite started from scratch. Angular v19 and TypeScript replaced the original
AngularJS stack. Modern Angular's signals-based reactivity model handles real-time
Firestore data streams cleanly — tasks, timers, and focus state all update across
the UI without imperative wiring. TypeScript gave the data layer the structure it
always needed: a Task, a Project, an Area
as first-class types, with Zod validation on every Firestore read.
Firebase Firestore replaced the original Realtime Database. The document model maps more naturally to the app's nested hierarchy. Hosting moved from GitHub Pages to Firebase Hosting on a custom domain, with a GitHub Actions CI/CD pipeline.
The styling approach changed completely. Custom SCSS — no component library — because this time the visual design was the point, not an afterthought. Tilled is built as craft software: intentionally designed for individuals by a solo developer, the software equivalent of something you'd find at a craft fair rather than a SaaS catalog. Colors were chosen for what they do psychologically — promoting focus and calm without draining energy. The hierarchy is visually obvious at a glance. The active focus is always clear. Cognitive load was treated as a constraint because the app is built for people like me.
Rough.js adds hand-drawn texture to decorative elements — progress bar segments,
dividers — reinforcing the handmade feel without sacrificing usability. Dark mode
is fully implemented via CSS custom property overrides, with theme preference
persisted to localStorage.
AI-assisted development as a repeatable methodology.
The rewrite was built using a structured AI-assisted development methodology — one I developed deliberately over the course of the project, not one I followed from a playbook.
The core challenge with AI coding assistants is that they have no persistent memory. Each session starts cold. Naive approaches treat each session as independent, which produces inconsistent code, repeated decisions, and accumulating technical debt. The methodology I built around this constraint is what made the difference.
The context file as source of truth. Every session begins with
Claude Code reading tilled-context.md — a living document that
captures the current architecture, component map, service interfaces, SCSS
conventions, key decisions, and a running log of what was built in each session.
At the end of each session, the document is updated. The AI isn't remembering;
it's being briefed. This reframes the constraint entirely: instead of trying to
give the AI memory it doesn't have, you give it a document that functions as
institutional knowledge.
Decision-first, execution-second. Architecture and design decisions happen in conversation before a single line of code is written. I use Claude to pressure-test ideas, explore edge cases, and think through downstream implications — the kind of back-and-forth that normally happens in a team. Once a decision is made, a precise implementation prompt is written specifying exact file paths, component structure, SCSS conventions, import patterns, and a clear exit condition. Claude Code executes to spec. The separation matters: designing in conversation and implementing from a prompt are different activities and require different prompts.
Surgical implementation, not broad refactors. Implementation prompts specify read-first, targeted changes. Claude Code reads the relevant files before modifying them and makes the minimum change required. This keeps diffs small and reviewable, and prevents the "helpful" rewrites that introduce subtle regressions.
Tests as the exit condition. Every session ends with
ng test --watch=false passing. New components require new unit tests;
changes to existing components require updated tests. The test suite isn't
ceremonial — it's what makes iterative AI-assisted development trustworthy over
time. After 49 sessions: 197 tests, 0 failures.
The AI didn't build Tilled. It helped me build it faster and more thoroughly than I would have alone — and working through the process made explicit a methodology I can now apply to any project.
From tool to product.
The original version — built in 2016 under the name projectr, used only by me — was the right tool for where I was. The rewrite gave me a chance to find out what I'd actually learned.
Some things didn't surprise me. Modern Angular, TypeScript, a document database, a proper CI/CD pipeline — obvious improvements the moment I sat down to plan. The architecture I wanted in 2016 and the architecture I built in 2026 weren't far apart in concept. The difference was execution: I had the skills and the tooling to do it properly this time.
What surprised me was how much the design ambition changed. The original was a tool I built to solve a problem. The rewrite became a statement about what software for individuals could feel like — considered, warm, built by a person rather than assembled from components. That wasn't in the plan when I started. It emerged from a decade of living with inadequate tools and knowing, specifically, what was missing.
That shift in ambition is why it's now called Tilled and lives at its own domain. A hobby project you make for yourself can be called anything. A product you want to put in front of other people — with a published philosophy, a white paper, a PWA that installs on your phone, and revenue features in the pipeline — should feel like it was built with that intention. Tilled does.