Deterministic, physics-based construction scheduling. BuildOS computes every task's earliest and latest possible dates, identifies which tasks are truly critical, and recalculates the entire schedule in under a second when anything changes.

The Scheduling Problem in Construction

A residential build has hundreds of tasks that depend on each other in complex ways. Framing can't start until the foundation is cured. Electrical rough-in can't start until framing is complete. Insulation can't be installed until rough-in passes inspection. Each dependency creates a constraint — and each constraint means that a delay in one task can ripple forward and push back the entire project completion date.

Most GCs manage this with a spreadsheet or a Gantt chart that they manually update. The problem: the moment something changes (a sub is late, an inspection fails, weather hits), the manual update doesn't happen — or happens days later, too late to adjust. By the time the schedule reflects reality, the team has already made decisions based on stale dates.

BuildOS solves this with a scheduling engine that recalculates automatically. Any change — a task marked complete, a delay reported, a duration updated — triggers an instant full recalculation of every date in the project.

Critical Path Method — Explained Simply

BuildOS uses a scheduling approach called Critical Path Method (CPM) — the same method used by NASA, large construction firms, and aerospace manufacturers for six decades. Here's what it means in plain terms:

Forward Pass — When Can Things Start?

Starting from the project's permit date, BuildOS calculates the earliest possible start and finish for every task, respecting all dependencies. A task cannot start until all its predecessors are complete. The forward pass answers: "Given everything that has to happen first, what's the soonest this task can begin?"

Backward Pass — When Do Things Have to Start?

Working backward from the required project completion date, BuildOS calculates the latest possible start and finish for every task before the end date is pushed out. The backward pass answers: "How late can this task start before it affects our completion date?"

Float — The Risk Buffer

Float is the difference between the latest a task can start and the earliest it can start. A task with 10 days of float can slip up to 10 days without affecting your completion date. A task with zero float is critical — any delay directly extends the project.

Task Dependencies — The Four Types

Tasks relate to each other in four ways, each representing a different real-world constraint. BuildOS supports all four, with optional lag time on each:

Lag days can be added to any dependency. A 7-day lag on a Finish-to-Start means Task B can't start until 7 days after Task A finishes — useful for curing times, permit processing windows, and inspection scheduling windows.

WBS Code System

Every task in BuildOS has a Work Breakdown Structure (WBS) code — a hierarchical number like 9.2 or 12.4. The code identifies which phase and sub-task a task belongs to. The major phases in a residential build:

How Task Durations Are Calculated

When a project is created from a permit, BuildOS doesn't just copy a generic schedule template. It calculates durations specific to this project using two models:

House Sizing Model (DHSM)

A 4,000 sq ft home takes longer to frame than a 1,800 sq ft home — but not exactly twice as long. BuildOS uses a Size Adjustment Factor based on the project's square footage relative to a standard-sized home. This factor is applied to every task's base duration, scaling the entire schedule proportionally. Inspection tasks are locked to standard durations regardless of house size, since the inspector's time is fixed.

The formula accounts for the non-linear relationship between size and labor: a home that's twice as big doesn't take exactly twice as long, because some tasks (like inspections) don't scale with size, and crew productivity improves on larger continuous runs of work.

Weather Model (SWIM)

Weather-sensitive tasks (WBS phases 1–9 and exterior work in phase 13) receive a weather buffer based on forecast conditions for the project location. BuildOS queries hourly weather forecasts from Tomorrow.io to assess:

• Rain risk: Precipitation above a threshold extends exterior task durations
• Frost risk: Below-freezing temperatures affect concrete work and exterior applications
• Heat risk: Extreme heat can slow certain labor-intensive outdoor tasks

Interior work (WBS 10–12, 14–16) is not affected by weather adjustments. Inspection tasks are also weather-immune — the inspector's schedule is what matters there.

Schedule Recalculation

The schedule recalculates automatically whenever any of the following occur:

• A task's percent complete is updated (from the web or field app)
• A subcontractor reports a delay via SMS (the Sub Liaison Agent creates a delay flag)
• A task's duration is manually adjusted by a superintendent or admin
• A new task dependency is added or modified
• A task is marked complete

Recalculation of a full 200-task project schedule completes in under 500 milliseconds — fast enough that it happens in the background without any loading wait for the user. The updated dates appear in the Gantt chart and task list immediately.

The Gantt Chart

The Gantt chart is the primary schedule visualization for Tom and Mike. It shows:

Performance Standards

The schedule engine is engineered to specific performance targets that are enforced automatically on every code change:

Schedule Integrity Guarantees

BuildOS makes a specific, hard guarantee about schedule accuracy: given the same project data as input, the schedule engine will always produce exactly the same dates as output — on any computer, at any time. This is called deterministic scheduling.

This matters because it means the schedule is auditable. If a client or lender questions why a completion date was set, the calculation can be reproduced step-by-step. There are no "it just showed that date" situations — every date has a calculable reason behind it.

This guarantee is enforced by automated tests that run on every code change, comparing the exact output against a known-correct baseline. Any change that causes even a one-day difference in any task's schedule fails the test automatically.