About

Built by someone who has had to explain the variance

Last Plan is not a software company’s idea of how construction planning works. It is a scheduler’s answer to a problem he kept being handed.

Where it came from

I am Apurv. I work as an independent consultant to US contractors in estimating, CPM scheduling and quantity take-off, with a background in data-center infrastructure — the kind of job where a two-week slip in a switchgear delivery reorganizes everything behind it.

The pattern was always the same. A general contractor would run a genuinely good pull-planning session — the right foremen in the room, real commitments made, a wall full of stickies that everybody believed. Then the session would end, someone would photograph the wall, and within a fortnight the plan people were actually working to lived in three or four places at once.

Two plans. One the field trusts and one the contract runs on. By the time they visibly disagree, the argument is about which one was ever real.

Why the existing tools did not close it

Digital pull-planning tools made the wall shareable, which is worth something. What they did not do was talk to the schedule the job is actually measured against. The category leader is openly described as not managing logic-driven master schedules or contract-level updates — teams run it alongside their CPM tool, in two systems, forever.

That gap is the whole reason Last Plan exists. Not a better sticky note: a shared board that the whole project team can work on together, where the commitments made in the session are still visible in week six, and where what was promised and what got finished are both a matter of record.

Over a decade of U.S. construction project-controls experience, including scheduling, estimating, and data-center projects. Last Plan is built by someone who has had to stand in front of a room and explain a variance, which is a different job from designing software about one.

How it gets built

Two things about how this is made, because they affect what you are buying.

Every production break is logged — cause, fix, and the guard added so it cannot come back. That log is a deliverable, not a diary: it is the reason the same class of bug does not show up twice. Layout, zoom, dialogs and the ticket editor have all been through it.

The domain rules are enforced, not suggested. A missed commitment requires a reason in the interface, in the API and in the database. A closed week’s PPC is frozen at three layers. Roles are enforced by Postgres row-level security, by API guards and by the interface — and the test suite fails if the three ever disagree. In a tool whose entire value is a trustworthy number, “we ask nicely” is not enforcement.

Where it is today

Last Plan is a working product, not a prototype. It is deliberately not large — there is no attachment feature, no notification system, no chat. What is there works, is tested, and is honest about its edges: it publishes the gaps alongside the capabilities.

If you run pull planning and a CPM master and you are tired of keeping both true by hand, that is exactly the problem this was built for. Come and break it on your own schedule.