Out-of-sequence stage detection

When a stage ends up sitting months away from the rest of the build, the schedule says so in plain words and offers to put it back.

What it is

The project modal checks whether the stages still follow their own running order. If a stage starts before the one above it — or one stage has run away from the pack — it names the offender, states how many days it has drifted, and explains why every date correction is producing absurd results.

Also called: my schedule went crazy · end date jumped to February · stages out of order · project says 165 days

See it, piece by piece
01

The schedule names the stage that broke it, and says how far out it is

A builder wrote in about a three-week pole barn his schedule insisted was 165 days long: every time he corrected the start date the end shot out to February, and every time he pulled the end back to September the start jumped to May. He assumed he was doing something wrong. He wasn't — a one-day permitting stage, first in the plan, had been placed five months after the build finished, with the final payment stranded in the middle of framing. The schedule now names the stage that drifted, states the days it is out by, and warns that until it is fixed every date correction will keep throwing the other end a long way out.

Build Schedule — stages out of order
Permitting is out of order

This job reads 165 days because that stage sits 151 days away from the rest of the work. Until that is fixed, changing the start or end date will keep throwing the other end a long way out.

Put the stages back in order — Sep 8 to Nov 14 (68d)

Keeps each stage’s length and this job’s start date; runs them back to back in plan order.

The banner naming Permitting, the 165 days it explains, and the repair button. The real screen, drawn from the product’s own design system. Sample data — no customer information appears here.
02

It blames one stage, not the five that look wrong because of it

When a single stage is stranded, every stage after it also fails the running order, so the obvious answer is a list of five names and no idea which one to touch. Where exactly one stage sits far away from where the rest of the work is clustered, only that one is named. Naming one stage is something a builder can act on; naming five is a shrug.

03

One button puts the stages back in order, and shows the result first

The repair re-lays every stage back to back in plan order from the job's own start date, keeping each stage's length and landing every start on a day the crew works. The button carries the outcome — "Put the stages back in order — Sep 8 to Nov 14 (68d)" — so you see the schedule you are about to get before you take it. The alternative is re-dating every stage on the job by hand.

04

It squashes the gaps rather than inventing a plan nobody wrote

Once the order is broken there is no way to tell a deliberate two-week wait for a sub from an accident, so the reflow runs the stages back to back from a date you choose. That is the one reconstruction that is honest about being a reconstruction. Guessing at the original intent would put wrong dates back with more confidence than they deserve.

05

Moving one stage on its own is still allowed

The stage-level date editor moves one stage and reflows nothing, which is exactly how a single mis-picked year does this much damage — and it is also what you need when the concrete sub can only come on the 14th. The freedom stays. The schedule simply notices when the result stops following its own order and says so.

How it works
  1. 1findOutOfSequence walks the task list in plan order; any stage starting before its predecessor is flagged
  2. 2Blame is then narrowed: when exactly one stage sits more than 45 days from the median of the others, only that one is named — 'Naming one stage is actionable; naming five is not'
  3. 3The warning states the project's current length and that changing the start or end date will keep throwing the other end a long way out
  4. 4A single button reflows the stages back to back in plan order from the job's existing start date, showing the resulting date range and length before anyone commits
Why we built it

A builder wrote in about a three-week pole barn that the schedule insisted was 165 days long: every time he corrected the start date the end date shot out to February, and every time he pulled the end date back to September the start date jumped back to May. He assumed he was doing something wrong. He was not — a one-day permitting stage, first in the plan, had been placed on day 333, five months after the build itself finished on day 206, with the final payment stranded in the middle of framing. The project controls were faithfully preserving a length that was itself nonsense, so every correction he made produced an absurd result and nothing on screen would tell him why. The schedule now names the stage that has drifted, says how far out it is, and offers to put the plan back in order.

The problem
  • A single mis-picked year silently poisoning every later date change
  • The builder having no way to see WHY corrections were failing
  • Project duration reading as nonsense with no explanation
Sound familiar?
What you get
The real cause is named instead of the builder blaming themselves
One click restores a sane schedule with the outcome previewed first
The freedom to move a single stage is kept rather than taken away
What's inside

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 →