Schedule, cost, risk and forensics on one project model.
Critical-path scheduling with the cost, estimating, risk, DCMA and delay-analysis modules already in the box. Reads and writes Primavera XER.
Fourteen days, five seats, every module. No card.
- A1000Site establishment
- A1040Access roads
- A1080Turbine foundations
- A1120Cable trenching
- A1160Substation civils
- A1200WTG erection
- A1240Grid energisation
Trusted by project teams
Primavera XER
import + export
MS Project MSPDI
import + export
Excel round-trip
with delete
DCMA 14-point
all 14 checks
AACE 18R-97
Class 5 → 1
Monte Carlo
P10 / P50 / P80
21 modules
one application
PostgreSQL
verified TLS
No screenshots of things that do not exist. Everything on this page is a capability you can see in a walkthrough.
The controls stack is five tools and a version-control problem.
Every arrow between them is a re-key, a version, and an argument about which number is current. The estimate is built once and typed in again as a budget. The risk register names activities that were renumbered two updates ago. The DCMA report was run against a schedule that has already moved on. None of that is anyone’s fault. It is what happens when schedule, cost, risk and quality live in four products that were never designed to share a model.
One model. Every discipline reads and writes it.
Change a duration and the total float, the earned-value curve, the DCMA score, the crash cost curve and the P80 date all move with it. There is no export step between disciplines, because there is no second database.
Schedule
CPM with float, calendars and constraints.
Cost & estimating
AACE estimates that become the budget.
Risk
Threats, opportunities and Monte Carlo.
Forensics
DCMA, delay analysis and crash.
Awaiting capture — WF32-BOP
Left icon rail expanded so all module icons show with their labels. Dark theme.
A CPM engine, not a bar chart.
Forward and backward pass, total and free float, negative float where it belongs.
Awaiting capture — WF32-BOP
Columns configured to show Total Float, Free Float, Constraint Type and Calendar. Scrolled to a region containing at least one negative-float row.
- All four relationship types with leads and lags.
- Work calendars, global and per project — non-working days, per-day working hours, holidays. Imported P6 hour counts convert using each activity’s own calendar, so a 12-hour calendar does not inflate every duration.
- Constraints including finish-no-later-than, which hold the scheduled date on reschedule and warn you when they are violated instead of silently moving.
- Level-of-effort activities whose span is driven by their relationships.
- Inclusive end dates. A one-day task ends the day it starts, the way P6 does it.
- Actuals drive the plan. Record an actual start or finish and the planned dates, progress and status follow.
- Duration from production rate. Quantity divided by crew output, calendar-aware.
Awaiting capture — WF32-BOP
Calendar manager dialog open on a 12-hour shift calendar with non-working days and holidays marked.
Awaiting capture — WF32-BOP
Critical path highlighted, float visible on nodes, layout settled.
The estimate becomes the budget. Once.
Versioned estimates classified AACE Class 5 through Class 1, with a markup build-up, that push their line items straight into cost assignments. Idempotently — push twice and the budget does not double.
Awaiting capture — WF32-BOP
An estimate open at AACE Class 3 with the markup build-up panel expanded and a composed unit rate visible on a line. Contextual ribbon tab showing.
- Unit rates composed from resource components, so a rate is a build-up you can defend rather than a number someone typed.
- Earned value on the same model as the schedule.
- One assignment solver. Edit units, hours, rate or cost and the other three re-derive from whichever one you touched.
- Capacity against demand, per resource. Over-allocation is not pooled away by aggregating across the pool.
- Multi-currency, with an exchange-rate matrix. Estimates price in their own currency and totals convert to your base.
- S-curves from activity dates alone. You do not need cost or resource data loaded to get a duration-based curve.
Awaiting capture — WF32-BOP
Earned-value dashboard populated.
Awaiting capture — WF32-BOP
Capacity-versus-demand histogram with at least one over-allocated resource showing red.
Awaiting capture — WF32-BOP
Baseline, planned and actual curves all rendered.
Threats, opportunities, and a P80 you can defend.
A register that treats opportunities with the same rigour as threats — each with its own probability and impact matrix and its own response strategies — linked both ways to the activities they affect.
Monte Carlo runs over three-point duration estimates and per-activity probability, on the same schedule you have open. Build a risk scenario and its P-level durations feed back into the CPM run, so you can see what the risk-adjusted plan actually looks like rather than reading a percentile off a chart and arguing about it.
Awaiting capture — WF32-BOP
Register open with the threat and opportunity matrices side by side, and a row showing its linked activity.
Awaiting capture — WF32-BOP
Simulation run to completion. Histogram plus cumulative curve, P10/P50/P80 markers visible, deterministic finish marked for contrast.
The analysis that usually costs a second licence.
Awaiting capture — WF32-BOP
All fourteen checks listed with a mix of passes and failures. One failing check expanded to its activity list.
DCMA 14-point, on the live schedule
All fourteen checks — logic, leads, lags, relationship types, hard constraints, high float, negative float, high duration, invalid dates, resources, missed tasks, critical path test, CPLI and BEI. Run against the model you have open, not against an export of it.
Forensic delay analysis
Overlay schedule snapshots period by period and see what slipped, when, and what drove it. Snapshots can come from a stored baseline, another project, a scenario, or a raw XER a claimant sent you. The engine classifies each activity’s critical-path role and delay cause.
Critical-path crash
Rank the secondary and tertiary float paths, build the crash cost curve, and find the date at which the critical path stops being the critical path as you compress. Then run Monte Carlo over the compression plan.
Awaiting capture — WF32-BOP
Three snapshots overlaid, slippage shown period by period, fragnet grouping visible.
Awaiting capture — WF32-BOP
Float paths ranked, crash cost curve rendered, critical-path changeover date marked.
It speaks XER.
Primavera XER in and out. Microsoft Project MSPDI in and out. Excel with a strict round-trip contract.
The import carries the things that usually get lost — activity constraints, per-activity calendars including 12-hour shift and holiday calendars, and the project data date. P6 stores durations in hours; the import converts them using each activity’s own hours-per-day, so a 10 or 12-hour calendar does not silently inflate every duration by a quarter.
The verbatim source file stays on the project record. When you export, the file is reconstructed from the original rather than synthesised from scratch, so what your client opens in P6 is recognisably the file they sent you, updated.
Excel export and import round-trips against a strict contract, with a Delete column for removals and reusable templates stored in the database. Bulk-edit a thousand activities in a spreadsheet and bring them back without corrupting the model.
Awaiting capture — WF32-BOP
XER import dialog showing the completed import summary: counts for activities, relationships, calendars, constraints, and the data date.
Proposes. Never commits.
It drafts a WBS, activities and relationships and stages them for your approval. Nothing enters the model until you approve it, row by row.
Awaiting capture — WF32-BOP
AI Check panel open over the Activities viewport with staged proposals, Approve and Reject controls per row, and a visible diff.
What it does
The module-scoped AI Check reviews the module you are looking at against the whole project — the schedule against the risk register, the estimate against the cost assignments — and stages what it would change in that module for approval.
What you should know
- Pinned to one named model, Claude Sonnet 5. There is no silent model switching.
- It runs on an Anthropic API key you supply. There is no vendor-supplied key — with no key entered, the assistant does nothing.
- Your key is stored in your browser and travels with each request to the server running the application, which forwards it to Anthropic. On a deployment we host, that server is ours. It is never written to the database.
- Using it sends project context to an external model provider. If that is not acceptable on your project, do not use the module.
- Chat transcripts are stored in your project database, attributed per person.
An organisation-wide switch to disable the moduleRoadmap
Your projects, in a database you can point at.
The application talks to PostgreSQL over an encrypted connection, with verification up to verify-full against a certificate authority you supply.
- The application runs against a PostgreSQL instance, and the connection supports full certificate verification with a CA you provide.
- Your project data, estimates, risk register and AI transcripts live in that database — not in a document store we operate alongside it.
- A self-hosted deployment you run on your own infrastructure, against your own PostgreSQL instance.
- A dedicated database per organisation on our infrastructure, for teams who would rather not run it themselves.
Neither is available yet. If your procurement process depends on one of them, say so on the call and we will tell you where it actually is rather than where we would like it to be.
Three ways in.
Planners and consultants
Import a client’s XER with its constraints, calendars and data date intact. Run DCMA on it. Overlay their last three updates and find what actually slipped. Hand back a file their P6 opens.
Small teams
The estimate becomes the budget. The risk register points at real activities. The resource pool is shared. Everyone is looking at the same model instead of four exports of it.
RoadmapSelf-service billing. Plans and seat limits are enforced; changing one is still a conversation.
Enterprise
Bring your security review; we would rather answer it before you buy than after. The connection to your database is encrypted and verifiable against your own certificate authority.
RoadmapRunning the application inside your own network. Your own PostgreSQL is already supported.
Where the product is today.
This is a new product. Rather than let you find these on a demo call:
Not yet: You cannot pay us yet.
There is no payment provider wired up. Plans and seat limits are real and enforced, but changing a plan is a conversation with us, not a form.
Not yet: No self-hosted deployment.
You can point the application at a PostgreSQL server you run, and enterprise customers do. Running the application itself inside your network is roadmap.
Not yet: Schema updates are manual.
Applying a schema update is a deliberate action, not automatic.
Not yet: No usage analytics.
The application collects no telemetry. That is a design position, and it means we cannot tell you what your team used last month.
Available: The engine is validated against P6.
Against real Primavera exports, with regression harnesses in the repository.
Available: Everything on this page is in the product now.
Every capability shown here is in the product today. Roadmap items are labelled Roadmap.
Every module is in every tier.
Risk analysis, DCMA and forensic delay analysis are not add-ons. Billed annually, per named seat.
Solo
$49per user / month
One planner. Every module.
- Most popular
Team
$89per user / month
Shared libraries. Every module.
Enterprise
$175per user / month
25 seat minimum. Licence and support terms.
The things people ask first.
Bring your worst schedule.
Send us an XER before the call and we will import it, run the DCMA assessment on it, and show you what we find.