In development

You are welcome to use it on real jobs. Feedback shapes what gets built next, and beta testers keep their pricing fixed for life.

In development · Beta pricing fixed for life

Tell us what you think

GX-04 · Programme

A programme built from real tasks

Most programmes are drawn once, printed, and quietly diverge from site within a fortnight. This one is generated from the tasks your engineers are actually working through, so it cannot drift without you seeing it.

Shot 05 · Hero

Gantt programme with phases across a multi-building job

2400 × 1350

The link to reality

One dataset, two views

The programme is not a separate document that somebody maintains. It is the same tasks, seen along a timeline. When a device is completed on site, the bar moves. When something is blocked, you can see what it delays without redrawing anything.

  • Gantt generated from the task register, not maintained alongside it
  • Programme start and end dates set per task, alongside the due date
  • Installation phases with a progress percentage on each task
  • Dependencies showing what cannot start until something else finishes
See the task register

Shot PG1

Programme bars against the tasks that generate them

1600 × 1000

Shot PG2

Resource allocation across tasks and engineers

1600 × 1000

Labour

Before you promise a date

A programme that ignores how many people you actually have is a wish. Duration, unit and required headcount sit on each task, and resource allocation shows who is already committed to what across the job.

  • Estimated duration and unit per task
  • Required headcount recorded alongside the estimate
  • Resource allocation visible across the project or per building
  • Blockers with an owner and a release stamp, so delays are evidenced

Why it matters commercially

Delay claims are won on records

When a job overruns, the argument is never about whether it overran. It is about why, and whose fault it was. A blocker raised at the time, owned by somebody, and released on a date is worth more in that conversation than any amount of recollection six months later.

  • Every blocker timestamped at the moment it was raised
  • Release stamped, giving a measurable duration for each delay
  • RFIs and site instructions logged against the work they affected
  • Full task history showing every date change and who made it
See RFIs and instructions

Shot PG3

Blocker log with raise and release timestamps

1600 × 1200

In this module

Everything in the programme

04

Programme overview

Gantt with phases, drawn from the task register itself.

Programme dates

Start, end and due dates held per task.

Installation phases

Phase and phase progress percentage on every task.

Estimates

Duration, unit and required headcount per task.

Resource allocation

Who is committed to what, across the job or per building.

Dependencies

Links between work that has to happen in sequence.

Blockers

Raised, owned and released, with a full audit trail.

Progress tracking

Completion by trade, floor and phase, calculated not guessed.

Get started

Stop maintaining two versions of the truth.

The programme and the task list should be the same thing. Put a real job in and see the difference.