Build Sunsama

KINDAreplaces $22/mosaves $264/yrback to the verdict

0%0 of 20 items done

Saved on this device only. Tick prerequisites first, then work the phases in order · do not start one until the checks above it pass.

A day view where you pull tasks from your lists and calendar into today, estimate each one, watch the planned total against the hours actually free, work through them, and close the day by deciding explicitly what moves and what was abandoned, with estimate accuracy tracked so the numbers get better.

estimated effort multi-daythe files for this build are in the project pack

RuntimeTypeScript with a small server and SQLiteCalendarRead-only calendar access for real availabilitySourcesTask import from where your work already livesTimeA library with full zone dataStorageLocal first with export

Before step 1

Everything below is assumed from the first step. Tick each one when you actually have it, not when you plan to.

installfree
Why Runs the application.
Get it nodejs.org, or nvm install 22. open ↗
Verify node --version prints v22 or higher
accountfree with an existing account
Why Available time is the number the whole ritual rests on, and a test calendar gives you a number that means nothing.
Get it Connect with read-only scopes, which is all this needs and all it should request.
Verify Busy time appears and matches your actual day
accountfree for most personal task tools
Why Retyping work into a planner is why planners get abandoned, usually in week two.
Get it An API token or export from your existing task tool. If your tasks live in your head, write them somewhere first, because this build cannot fix that.
Verify Tasks import with stable identifiers
decidefree, but it takes two weeks
Why Estimate accuracy needs a sample, and the shutdown ritual only shows its value once you have moved the same task three times and had to admit it.
Get it Decide to run it for two weeks with real work before judging it, and record actual time even on the days you forget the timer.
Verify Two weeks of plans exist with actual times recorded
decidefree
Why A planning tool that reads as criticism gets abandoned, and you cannot audit your own wording because you know what you meant.
Get it Ask someone to read the report strings and say whether any of it reads as judgement.
Verify A second reader's notes are recorded

Data model

Create these before the first phase that stores anything. Changing a table later is the expensive kind of change.

- tasks(id, source, external_id, title, notes, created_at, archived_at, project)
- plans(id, on_date, planned_minutes, available_minutes, closed_at, reflection)
- plan_items(id, plan_id, task_id, ordinal, estimate_minutes, actual_minutes, state, moved_to_plan_id) · state is planned, done, moved or abandoned
- sessions(id, plan_item_id, started_at, ended_at) · time actually spent, which is what makes estimates improve
- busy(id, source, starts_at_utc, ends_at_utc) · from your calendar, so availability is real
- A task that is not finished is either moved with a decision or abandoned with one. Nothing rolls over silently.

Environment variables

These go in a .env file the app reads at startup. The pack's .env.example is this table as a file · copy it, never commit the filled-in version.

Variable	Needed	Example	Where the value comes from
`DB_PATH`	required	`./data/plans.db`	Plans, tasks and sessions. A record of how you work, so treat it accordingly.
`WORKING_HOURS`	required	`09:00-17:30`	Local wall clock, in your zone.
`TIMEZONE`	required	`Europe/London`	The zone working hours and day boundaries are expressed in.
`DAILY_BUFFER_MINUTES`	required	`90`	Subtracted from available time for the things that always happen. Tune it from your own history.
`ACCURACY_MIN_SAMPLE`	required	`30`	Completed tasks required before a bias figure is shown.
`MOVE_FLAG_THRESHOLD`	required	`3`	Times a task can be moved before it is flagged, without a verdict attached.

The build, in order

1
Real availability, honestly counted
The application knows how many hours you actually have today.
1. Busy time only. This application never writes to your calendar, which is a deliberate difference.
  Files src/calendar.ts
2. Working hours minus busy time minus buffer, in your zone.
  Files src/availability.ts
3. Shown, not hidden in settings. It is the number that makes the capacity honest.
  Files src/ui/Capacity.tsx
done when · tick each as it passes
watch out
- Counting every non-meeting minute as available produces a capacity figure nobody can hit, and a planner that is wrong on the first number is a planner people stop trusting. Subtract a realistic buffer for interruptions and admin, and let the user tune it from the gap between planned and actual over time.
next phase
2
Pulling work in from where it lives
You plan from your real tasks rather than retyping them.
1. Source plus external identifier, unique. Re-import is then a no-op.
  Files src/import.ts
2. And say clearly where it is not possible, rather than diverging quietly.
  Files src/sync.ts
3. A task deleted at the source stays on the plans it was on. History is not editable by a later deletion.
  Files src/tasks.ts
done when · tick each as it passes
watch out
- A planner that requires you to retype your work becomes a second list that diverges from the first within a week, and then neither is trusted. Import with stable identifiers, and if the source cannot accept a completion back, say so rather than letting the two lists silently disagree.
next phase
3
Planning the day, with the total in front of you
You cannot plan eleven hours of work into a six hour day without noticing.
1. Pull from backlog, order, estimate. Keyboard reachable, because this happens every morning.
  Files src/day.ts
2. Planned against available, updating live. Prominent rather than tucked away.
  Files src/ui/DayTotal.tsx
3. Counting them as zero makes the total a lie. Flag and ask.
  Files src/day.ts
done when · tick each as it passes
watch out
- Hiding the total until the end of planning defeats the purpose, because by then you have already committed. Show it continuously and prominently, since the moment of adding the task that tips the day over is the moment the information is useful.
next phase
4
Working, and recording what it took
Actual time is captured with enough ease that it actually gets captured.
1. From the day view, keyboard reachable.
  Files src/timer.ts
2. Same number of actions. This is the path most days will take.
  Files src/timer.ts
3. A pair of numbers. No commentary, because the number is the information.
  Files src/ui/TaskRow.tsx
done when · tick each as it passes
watch out
- A time tracker that only works if you remember to start it captures a partial and misleading record, and the partial record is worse than none because it looks complete. Make after-the-fact entry as easy as the timer, since most days you will use it.
next phase
5
The shutdown, which is the point
The day ends with a decision about every unfinished thing.
1. Move to a named day, or abandon with a reason. No default and no rollover.
  Files src/shutdown.ts
2. Same effort as moving. It is frequently the correct choice and should not feel like failure.
  Files src/shutdown.ts
3. A task moved several times is telling you something. Surface it without a verdict.
  Files src/shutdown.ts
done when · tick each as it passes
watch out
- Automatic rollover is the feature that quietly destroys this: a task moved silently for three weeks is a task you have decided not to do without ever admitting it, and the list grows until the planner is abandoned. Require the decision, and make abandoning as easy as moving, because it is often the right answer.
6
Estimate accuracy and exportproduct builder
Your estimates improve because you can see how wrong they have been.
1. Across many tasks, by project and size. Not individual misses.
  Files src/accuracy.ts
2. Below it, no figure. A ratio from four tasks is noise presented as insight.
  Files src/accuracy.ts
3. A banned word list checked at build. Underestimating is normal and the tool should say so.
  Files scripts/copy-lint.ts
done when · tick each as it passes
watch out
- Reporting individual misses invites self-criticism and teaches nothing, because any single estimate can be wrong for good reasons. The useful figure is the systematic bias across many tasks, which is stable, actionable and impersonal.

what this build does not replace

The integration breadth of the hosted product.
Writing time blocks back to your calendar.
The accumulated ritual design that makes the paid product work.
Mobile applications.
integration breadth
calendar two-way sync
daily ritual design
mobile apps
analytics
reliability

after v1, if you want it

A weekly review reading back the fortnight's decisions rather than its completions
Per-project time totals, which most freelancers need for invoicing anyway
An estimate suggestion from your own history for a task that resembles a previous one

Need the files? The project pack on the verdict page hands your agent the whole brief · more tasks & calendar.