Pomodoro vs Timeboxing vs Flowtime

Three focus methods keep showing up in the same arguments, and they are not competing versions of the same idea. Pomodoro, timeboxing and Flowtime each fix a different variable: the length of the block, its position in your calendar, or nothing at all. Pick by what your work actually breaks on — starting, over-running, or being cut off mid-thought.

#TL;DR

• Pomodoro fixes block length: 25 minutes on, 5 off, repeat.
• Timeboxing fixes block position: a named task in a calendar slot.
• Flowtime fixes nothing — work until you need a break, then log it.
• Pomodoro helps you start; timeboxing protects the hours; Flowtime protects flow.
• Match the method to the task, not to your personality.

#What is the difference between Pomodoro, timeboxing, and Flowtime?

All three make you work on one thing at a time. What separates them is which variable they nail down and which they leave loose.

#Pomodoro: a fixed unit you count

Francesco Cirillo's method sets a timer for 25 minutes, forbids task switching until it rings, then gives you 5 minutes off; after four rounds you take 15 to 30 minutes. The official site is blunt that the timer is only the entry point — the full technique also covers daily planning, interruption handling, and effort estimation, which is where the fixed unit earns its keep. Because every block is the same size, "this took four pomodoros" is a number you can compare against last week.

#Timeboxing: a calendar slot with a hard edge

Timeboxing comes out of software project management — James Martin's Rapid Application Development (1991) popularised the term for fixing the schedule and flexing the scope. Applied to personal work it means migrating items off a to-do list and into your calendar with a start time, an end time, and a name. Marc Zao-Sanders argued in Harvard Business Review that timeboxing outranked 99 other productivity habits in a survey of what people found useful, largely because a to-do list has no sense of how many hours you actually own.

#Flowtime: work until you're done, log what happened

Flowtime was published by Zoë Read-Bivens in August 2016 as an explicit reaction to what she called "PomoStress" — the anxiety of a countdown running while you are finally getting somewhere. You pick one task, write down the start time, work with no timer, and stop when you genuinely need to. Then you record stop time, whether you were interrupted, work time in minutes, and take a break sized to the block. The only hard rule she keeps from Pomodoro is unitasking.

Here is the same comparison in one place.

#Which focus technique should I use?

Pick by failure mode. Ask which of these three sentences you have said this month.

#"I can't make myself start"

Pomodoro. A 25-minute commitment is small enough to accept when the task feels large, and the ritual of starting a timer is a real commitment device. This is also why Pomodoro suits triage-shaped work — inbox, code review, bug backlog — where each unit is small and the friction is entirely at the start.

#"The day disappeared and I did none of the important work"

Timeboxing. The failure here is not focus, it is allocation: important-but-not-urgent work never wins against a list of quick items. Putting the task in a slot converts a vague intention into a decision you made in advance, when you were calmer and better at prioritising than you will be at 2pm.

#"The timer keeps cutting me off right when it gets good"

Flowtime. If you routinely hit "skip break" or resent the ring, the fixed interval is costing you more than it is buying. Flowtime keeps the logging and the unitasking and drops the part that was interrupting you.

#Why does the Pomodoro timer break your flow state?

Because a timer is an interruption you scheduled. That is the whole trade: Pomodoro accepts a small self-inflicted interruption to prevent larger external ones.

#What the interruption research actually says

Gloria Mark and Daniela Gudith's CHI 2008 study found people finished interrupted tasks faster, not slower — but paid for it with higher stress, frustration, time pressure and effort. That is the finding worth carrying into this decision. An interruption does not necessarily wreck your output; it taxes you. A ring at minute 25 of a hard debugging session is cheap on throughput and expensive on morale, which is exactly the complaint Flowtime was built around.

#Why Flowtime logs interruptions instead of preventing them

Cirillo's method treats an interruption as something to record and defend against. Read-Bivens' method treats it as data: mark the interruption in the log, handle it, resume. Neither pretends interruptions can be eliminated. The difference is that Flowtime's log tells you, after two weeks, which hours of your day are structurally un-protectable — and that is a scheduling problem, not a willpower problem.

#How long should a Flowtime break be?

The original cheat sheet gives a ladder rather than a constant. Per Read-Bivens' Flowtime cheat sheet, scale the break to the block you just finished, and adjust from there:

She is explicit that these are starting points. The one instruction that is not optional: set a timer for the break. An untimed break is how a 7-minute reset becomes forty minutes of scrolling.

#How to run each method in a browser timer

You do not need three apps. All three reduce to a countdown, a stopwatch, and a text file.

#Running Pomodoro with a preset URL

Open the browser timer at a fixed duration and bookmark it. Because the duration lives in the URL, the setup survives a reload, a new laptop, and a shared bookmark bar:

timer.ikit.app/?minutes=25
timer.ikit.app/?minutes=5

Two bookmarks, no configuration, nothing to remember at the moment when remembering is hardest.

#Running a timebox against a wall-clock deadline

A timebox ends at a wall-clock time, not after a duration — "until 11:30", not "for 50 minutes". That is what a countdown to a specific time is for. It also means a late start eats the box rather than pushing everything after it, which is the entire point of fixing the schedule and flexing the scope.

If you are computing that remaining time yourself, work from the deadline rather than counting ticks:

const endsAt = new Date("2026-08-21T11:30:00");
const msLeft = endsAt - Date.now();
const minsLeft = Math.max(0, Math.floor(msLeft / 60000));

Recomputing from the system clock is also what keeps the number correct after a background tab throttles your interval.

#Running Flowtime with a stopwatch and a log

Flowtime needs elapsed time, not a countdown, so use a stopwatch with laps and mark a lap at each interruption. The log itself is six columns — Read-Bivens' original is a paper grid, but plain text works and is easier to analyse later:

task,start,stop,interrupted,work_min,break_min
auth bug,09:12,10:04,1,52,7
release notes,10:11,10:33,0,22,3
schema review,10:36,11:29,2,53,7

Keep it as CSV and you can push it through a CSV to JSON converter whenever you want to chart it, without ever handing your working patterns to someone else's server.

#How to pick the method that fits your brain

There is a tempting version of this question — "am I a Pomodoro person or a Flowtime person?" — and it is the wrong one. The same person needs different structures for different tasks.

#Match the method to the task, not your personality

Sort by warm-up cost. Work with a long warm-up (debugging, writing, reading a spec, learning something new) loses the most to a fixed interval, so Flowtime or a long timebox wins. Work with essentially no warm-up (triage, review, admin, replies) loses nothing to interruption and gains a lot from a small starting commitment, so Pomodoro wins. Work that competes badly for attention needs a calendar slot regardless of which interval runs inside it.

• Long warm-up, low interruption risk → Flowtime
• Long warm-up, high interruption risk → timebox, then Flowtime inside it
• Short warm-up, hard to start → Pomodoro
• Keeps getting deprioritised → timebox first, method second
• Fatigue is the limiting factor → any method, but time the breaks

#Run a one-week trial, not a one-day trial

One day tells you nothing: novelty flatters whichever method you tried most recently. Run one method for five working days, log every block, and only then compare. Log the same three fields whatever you are testing — task, work minutes, interrupted yes/no — so the weeks are comparable. That comparability is the real deliverable, and it is the one thing all three methods agree on.

#The decision table

Whichever you pick, the timer is the smallest part. Cirillo's estimation sheets, the calendar slot, and Read-Bivens' six-column grid all exist for the same reason: after two weeks, you stop guessing how long your work takes.

#References

• Pomodoro® Technique — Time Management Method — Francesco Cirillo's official site; used for the scope of the full method beyond the timer (planning, interruption handling, estimation).
• The Flowtime Technique — Zoë Read-Bivens' original 2016 write-up; used for the six-column log, the unitasking rule, and her reasoning against fixed intervals.
• The Flowtime Technique Cheat Sheet — companion post; source for the break-length ladder in this article.
• The Cost of Interrupted Work: More Speed and Stress — Mark, Gudith & Klocke, CHI 2008; used for what interruptions actually cost (stress and effort, not completion time).
• How Timeboxing Works and Why It Will Make You More Productive — Marc Zao-Sanders, HBR 2018; used for the case that calendars beat to-do lists.

#Related on iKit

• Why the Pomodoro 25/5 split still works — the long-form case for the fixed interval this article compares against.
• How to run an accurate countdown in the browser — the deadline-based timing a timebox depends on.
• Online stopwatch with lap times, explained — laps are how you mark interruptions in a Flowtime log.
• Preset timer URLs for 5, 10 and 25 minutes — the bookmark trick that makes Pomodoro setup a one-click affair.
• Why background tabs pause your JavaScript timer — why a focus timer must recompute from the clock, not count ticks.
• Why setInterval drifts and how to build a drift-free timer — the underlying reason a 25-minute block can quietly become 26.
• Build a browser alarm sound with the Web Audio API — the end-of-block signal, for whichever method you land on.