Pace
Open appI am writing a novel: fifteen chapters, five thousand words each. I know I write about a thousand words when I sit down. What I could not tell you was when I would finish, and the arithmetic that looked like it should answer that turned out to be the wrong arithmetic.
Seventy-five thousand words at a thousand a sitting is seventy-five sittings. That number is easy. The number that decides everything is how often I actually sit down, and that is the one I had no honest answer for. At seven sittings a week I finish in about two months. At one a week I finish in about a year and a half. Both are fair descriptions of "a thousand words a sitting, not every day", and fifteen months sit between them.
So I built Pace. You give it a target, it measures the rate you actually work at, and it shows you the date that rate implies. Then it prices every change you could make, in days.
Two dates, not one
Every pace calculator I could find lets you enter your good-day number and hands back a date built on it. That is a pleasant lie. If you write a thousand words on the three days a month you write, your real pace is closer to a hundred a day, and the date you were given is fiction.
Pace shows two dates side by side: the one your stated goal implies, and the one your log implies. The distance between them is the largest number on the page, because that gap is the whole point. Your measured pace divides sessions by elapsed weeks, not by the weeks you happened to work, so the days you did nothing are in the arithmetic where they belong.
The number nobody can estimate about themselves
Ask anyone how often they write and they will round up. Not dishonestly, they just do not know. So Pace does not ask. It keeps a calendar of every day since you started tracking, and derives your frequency from what is actually there.
The calendar is the honest part of the interface. Mine shows a dense first fortnight and then a long thin stretch of blanks, and that shape explains the finish date better than any sentence could. Logging is one number a day, because every extra field is a reason to stop.
What each choice costs
Knowing the date is useful once. What keeps me coming back is the ledger underneath it, which takes the same projection and runs it again with one thing changed, so every row is directly comparable. Skip the next week and the book arrives seven days later. Add one more sitting a week and it arrives four months sooner.
The row I did not expect: writing half as much per session but showing up daily beat my actual burst pattern by nearly six months. Every piece of writing advice says produce more per session. My own numbers said the opposite, that frequency is the lever and volume is not. A tool that runs on your real log can tell you that. A blog post cannot.
Pricing decisions this way also changes how the bad news lands. A date on its own is a verdict, and a demoralizing one is easy to close the tab on. A list of prices is something you can act on, so the honest number stops being a judgement and starts being useful.
Starting when you are already halfway
I found this problem in my own first hour of use. I did not start tracking on day one of the novel, I started forty thousand words in, and neither option available to me was any good. Backdate the start and it says I have done nothing. Log the back catalogue as a single session and my average sitting becomes forty thousand words, which produces a date that is pure fantasy.
So a project carries a head start: work finished before tracking began. It counts toward the target and is deliberately kept out of every pace figure. Progress and pace are two different numbers, and separating them is what lets you pick this up partway through and still get an honest answer. It also means the tool is useful on the first day, before anything is logged, because it projects from where you actually are rather than from zero.
What it does
- Two dates and the gap. The date your goal implies, the date your log implies, and the distance between them as the headline figure.
- Pace measured, not declared. Sessions per week and amount per session both come from the log, with the empty days counted against you.
- A cost ledger. Each row is the same projection with one input changed, priced in days: skip a week, add a session, halve each session but show up daily, or trim the target.
- A what-if slider. Drag your sessions per week and watch the finish date move in real time.
- A continuous habit calendar. Every day since you started tracking, shaded against your goal for one session, with your show-up rate, current streak, best streak, and longest gap.
- A burn-up chart. What you have recorded, then a fan of projections from today: your measured pace, your goal pace, and wherever the slider sits.
- A head start. Record what was done before you started tracking without corrupting the projection.
- Deadlines. Set one and Pace tells you how far past it your real pace lands, or how much room you have.
- Any unit. Nothing below the labels knows what a word is. Words, miles, pages, reps, or hours all work the same way.
- Backup to a file. Save every project and its log, and load one back. Loading appends rather than replaces, so an import cannot overwrite work you already have.
How it's built
Everything lives in your browser. There is no account, no backend, and nothing is uploaded, so a backup file is the only copy that survives clearing site data.
The projection maths sits in one file with no framework in it and is covered by fifty tests, because a projection that is subtly wrong is worse than no projection at all. The tests pin the things that would be easy to get quietly wrong: that a head start never leaks into the average session, that skipping a week costs exactly seven days, and that the empty days stay in the denominator.
Built with Vite, React, and TypeScript. The source is on GitHub.