Four statuses — Planned, In Progress, Delayed, Completed — plus editable Actual Dates and a variance readout ('Actual: 7 days (planned 5) · +2 late'). Marking a stage in progress stamps the start; completing it stamps the end and computes actual days and variance.
Also called: planned vs actual · how late are we · stage running over · days behind
Every stage records what it actually took, beside what you said it would
Marking a stage In Progress stamps the real start; completing it stamps the finish and works out the run — "Actual: 7 days (planned 5) · +2 late". Those durations used to be worked out on screen and thrown away, so every completed stage carried a blank actual duration behind it and no builder could say how long framing really takes on his own jobs. Both dates stay editable, because the crew tells you on Monday what happened on Friday.
The plan is frozen at kickoff so nobody can move the goalposts
Change a stage from five days to seven halfway through and the estimate you are measuring against moves with it — a job that ran two weeks over reads as on time, because the plan was quietly edited to match reality one stage at a time. What a stage was figured to take is locked the moment the job starts. Where it sits on the calendar stays free to move, because rescheduling a job that slipped is not the same act as re-estimating it.
Late and early are written on the bars themselves
A finished stage carries its variance on the bar — +3d in red, −2d in green — so the jobs that ran over are visible from the other side of the office without opening anything. The bar is the only place most people will ever look, which is why the number lives there instead of in a report someone runs at the end of a quarter.
The numbers are computed once, not by whichever screen happened to save
Actual days and variance are worked out where they are stored, on every write, rather than being sent up by the screen doing the saving. The office, the crew's phone and the analytics all read one figure, so there is nothing to reconcile. The alternative is a bug on one screen quietly writing numbers every other screen then trusts.
Every change to an actual date says who moved it, and from what
Editing a real start or finish records the old value, the new value, the job, the stage and the person. Actual dates decide crew pay, delay claims and what the customer gets told, so a quiet correction three weeks after the fact is exactly the kind of thing you want a line about.
- 1updateTaskStatus updates local state first for instant response, then upserts the crew stage log in the background
- 2Actual start and end are separately editable, and every change writes an audit log entry naming the old and new values
- 3actual_days and variance_days are DERIVED in the database on every write rather than sent by the client
- 4Variance is measured against the baseline set at project start, not against a duration a mid-project edit could rewrite
- 5Selecting 'Delayed' opens the delay reporting flow instead of just flipping the status
Actual durations and variance were calculated and shown on screen, then thrown away — written into the page and never into the record, so the numbers survived one session and vanished on reload. Every completed stage in the system carried a blank actual duration behind it, which is why nobody could answer how long framing really takes on their own jobs. Actuals are recorded as they happen, against a plan frozen at the start, because you cannot measure 'we ran three days over' if the estimate quietly follows the actual around.
- Variance metrics that were never persisted
- Estimates silently following actuals so nothing could be measured
- No record of when a stage really started or ended
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →