The estimate is frozen at project start

What you said a stage would take is locked when the job starts; where it sits on the calendar stays free to move.

What it is

Planned_days becomes immutable once a project is live, on both the stage instance and the analytics log. planned_start_day deliberately remains movable — 'Duration = the commitment; start day = where it currently sits.'

Also called: baseline days · planned days can't change · someone edited the plan mid job

See it
The estimate is frozen at project start
Apr
May
Jun
Jul
Ivy Brubaker — Equipment Storage
Framing
Sutter Kline — Hobby Shop
Concrete
Sutter Kline — Equipment Storage
Trim
Ivy Brubaker — Equipment Storage
Framing
Sutter Kline — Riding Arena
Concrete
Framing crewConcrete crewTrim crew
Analytics row showing 'planned 5 (baseline) / actual 7 / +2' with the baseline unchanged after a mid-project edit — stage-analytics route. Sample data — no customer information appears here.
How it works
  1. 1The freeze trigger's protected set was extended to include planned_days
  2. 2Variance is computed against baseline_days, set once at start
  3. 3Rescheduling a job a week later does not touch the baseline
Why we built it

Changing a stage from five days to seven mid-build rewrote the original estimate, so the plan every comparison measured against was itself moving. A job that ran two weeks over showed as on time, because the plan had been edited to match reality one stage at a time. The estimate is frozen the moment a job starts; what actually happens is free to move.

The problem
  • Estimates moving to match actuals
  • Rescheduling being confused with re-estimating
Sound familiar?
What you get
Variance is a real measurement
Jobs can still be re-plotted when they slip

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 →