Reaching 1,000-task schedules was an important milestone, but it was never the real destination. In construction planning, meaningful projects often grow far beyond that scale. Once a programme starts representing full project structures, multiple work packages, detailed sequencing logic, and future resource constraints, the task count rises very quickly.
That is why the next stage of development is focused on moving from 1,000-task optimisation toward 10,000-task schedules.
This is not simply a matter of making the same process run on a larger file. At that scale, the engineering challenge changes. Data handling, rendering, schedule evaluation, dependency processing, and optimisation runtime all begin to matter in a much more serious way.
Why scale matters
Small schedules can be useful for testing. They prove that the logic works, that dependencies are respected, and that the optimisation engine is capable of producing valid alternatives. But real planning value appears when the engine can work on schedules large enough to resemble actual project environments.
A 10,000-task model is closer to the level where full construction programmes begin to show their real complexity. More trades are involved. More sequencing interactions appear. More summaries and sub-summaries are required. More dependency patterns overlap. The schedule becomes less like a simple list of activities and more like a living operational system.
That is the scale where manual schedule improvement becomes increasingly difficult, and where mathematical search begins to justify itself more clearly.
The challenge is not only optimisation
When people hear that a system is scaling from 1,000 to 10,000 tasks, they often assume the main problem is only the algorithm. In reality, the challenge is broader than that.
The optimisation engine is one part of the problem, but large schedule handling also depends on:
- parsing and loading large activity sets efficiently
- processing dependency logic without excessive overhead
- keeping memory usage under control
- rendering large Gantt structures clearly in the browser
- avoiding UI slowdown when thousands of rows and links are displayed
- preserving schedule validity while searching large decision spaces
In other words, scaling is not one improvement. It is a chain of improvements across the full system.
What changes when the schedule becomes large
At smaller scales, many design choices appear acceptable because the system can absorb inefficiency. At larger scales, those same choices begin to multiply their cost.
A minor delay in dependency parsing becomes significant when repeated across thousands of tasks. A rendering method that feels smooth at 500 rows may become heavy at 10,000. An optimisation loop that evaluates modest populations quickly may begin to slow once the candidate schedules themselves become larger and more constrained.
This is why the move toward 10,000 tasks is not being treated as a cosmetic benchmark. It is being treated as a systems engineering problem.
Current development direction
The current focus is on building stronger foundations for scale rather than forcing larger schedules through an architecture designed for smaller ones.
That includes improving the way task collections are prepared, reducing unnecessary work during schedule evaluation, and becoming more selective about what the interface renders at any one time. As schedule size grows, efficiency is no longer a nice addition. It becomes part of the product logic.
The same principle applies to optimisation. The goal is not only to search harder, but to search more intelligently within a valid space of solutions.
Moving from 1,000 to 10,000 tasks is not a simple linear increase. It changes the pressure on parsing, logic handling, rendering, and optimisation performance across the system.
Runtime becomes a product issue
Performance is often treated as a technical detail, but in optimisation software it affects the user experience directly. If runtime becomes too long, experimentation slows down. If the interface becomes too heavy, large schedules become harder to read and trust. If results arrive too slowly, the usefulness of the optimisation loop starts to weaken.
That is why runtime is not being approached only as an engineering metric. It is also being treated as part of usability. A planning engine should not only be mathematically sound. It should support practical decision-making at a pace that remains useful.
Preserving logic at scale
A large schedule is only valuable if its logic remains credible. For that reason, scaling is not about simplifying the schedule into something easier to optimise. The purpose is the opposite: to preserve realistic dependency behaviour while making the engine more capable of handling it.
Construction programmes do not operate on isolated activities. They operate on linked work sequences, trade interactions, phased areas, summary structures, and constraint relationships that affect what can move and what cannot.
As the engine grows, this logic has to remain intact. Otherwise, scale would come at the cost of realism, and that would undermine the purpose of the platform.
Why this stage matters for the wider vision
The move toward 10,000 tasks is important not only because it improves one benchmark, but because it prepares the platform for what comes next. Broader decision optimisation depends on scale.
Once resources, mitigation strategies, buildability checks, and future BIM-connected planning rules are introduced, the system will need to handle more than task ordering alone. It will need to manage a richer and heavier problem structure. That makes scalable foundations essential.
In that sense, this stage of development is not separate from the larger product vision. It is one of the steps required to reach it.
What success looks like
Success does not simply mean loading a very large file and claiming the system can handle it. Real success means something more demanding:
- large schedules can be loaded and interpreted reliably
- dependency structures remain valid and transparent
- the optimisation loop remains practical to run
- the interface remains usable at scale
- the results still support real planning decisions rather than synthetic demonstrations
That is the standard being worked toward.
From proof of concept to real scheduling engine
Reaching 1,000 tasks proved that the optimisation concept works. Moving toward 10,000 tasks is about proving that the system can evolve into something much closer to a real scheduling engine.
This is still an active stage of development, but it is a meaningful one. Every improvement in scale, runtime, and structure moves the platform further away from a small prototype and closer to a serious optimisation environment for complex construction planning.