Alpha went live, and everything changed
The July 28 update closed by saying the architecture had “stopped being the headline by itself and started enabling the product.”
That turned out to be the last update written entirely from the inside.
Since then, ProjectXL has been in the hands of alpha testers, and the character of the work changed completely. For most of this year, the question was can the architecture carry a real planning tool? Since the end of July, the question has been what happens when someone points it at a real project?
Those are very different questions, and the second one is far less flattering.
Five releases shipped in the first two weeks of alpha — 1.0.13 through 1.0.17 — most driven directly by what testers encountered. More than fifty governed build packets have closed since July 28.
Here is what actually changed, grouped less by feature than by what forced us to change it.
What real projects broke: scale
The alpha datasets were bigger than anything ProjectXL had been developed against. A schedule with thousands of activities behaves nothing like a schedule with two hundred, and several surfaces that felt instant in development became multi-second stalls.
Scale became the single largest work stream of the month.
-
The schedule network canvas was rendering every node, edge, and hit target on every frame, regardless of what was actually visible. On a large network, a single pan could lock the interface for more than eight seconds, with 99% of that time spent in main-thread work. The canvas now renders only what falls inside the viewport. More importantly, every render path — nodes, links, hammocks, hit zones, overlays — was audited against that rule rather than fixing only the obvious bottleneck.
-
The Gantt and work package timing surfaces got the same treatment: row virtualization, followed by a sweep to ensure overlays, gridlines, and dependency lines respect the visible window instead of the full scroll extent.
-
Network linking was reworked so creating and editing dependencies remains responsive as the graph grows, while duplicate graph rebuilds across the host-to-canvas wire were eliminated.
-
Snapshots moved to a storage schema designed for large project structures. Capture and restore on large plans is no longer a “go get coffee” operation.
-
Import and recalculation were separated so the engines do not repeatedly recompute a project while it is still being ingested.
None of this is visible as a new feature.
All of it is the difference between a tool you can demo and a tool you can use.
What real users broke: trust
The other category of alpha feedback was quieter and more important:
Did my edit actually save?
A cluster of defects made editing feel unreliable in ways that were difficult to describe and, in practice, worse than an outright error: a save that reordered rows, an editor that appeared to accept a change but did not persist it, a dirty-state indicator that disagreed with what was actually saved.
We stopped feature work in that area and built a proper model for it.
-
A save trust contract now applies across editing surfaces: a change either commits visibly or fails visibly. There is no third outcome.
-
A dirty/draft state model was designed so the product has one authoritative answer to “are there unsaved changes?” rather than each surface inventing its own.
-
A table corruption defect was found in Excel writes performed while a table filter was active. Table writes now preserve that state safely around the operation.
-
Validation feedback gained cell-level navigation, so an issue can take the user to the exact place that needs attention rather than the general vicinity.
These are not especially exciting release-note bullets. They matter because once a user doubts whether the application saved an edit, every subsequent interaction becomes suspect.
Trust is a feature.
Then somebody opened two workbooks
The most structurally significant work of the month began with an entirely reasonable thing for an alpha tester to do:
They opened two ProjectXL workbooks at once.
ProjectXL had originally been built around an implicit assumption that one project workbook was active. Once there were two, assumptions about state ownership that had been harmless became ambiguity: which workbook does this command, window, message, or piece of state belong to?
Fixing that required a chain of architectural corrections across workbook scoping, close lifecycle, per-window state ownership, message boundaries, and ambient workbook resolution.
The resulting rule is much simpler than the work required to enforce it:
Every piece of project state must be able to answer which workbook it belongs to.
The final boundary-closure work reduced measured violations from 60 to 11 and eliminated both of the highest-severity classes.
Alongside that work, window management was rebuilt for actual multi-monitor use. Floating workspaces now remember the monitor, coordinate frame, and size they belonged to — while still recovering safely when that monitor is no longer there.
New capability
August was not entirely repair work. Three additions materially changed what can be modeled and authored in ProjectXL.
Custom fields
ProjectXL now has a full custom-field authoring system: define fields, evolve those definitions safely, edit values in context on the entities they belong to, or work with them in bulk through a dedicated Excel editor.
Required custom fields also participate in project readiness just like built-in fields.
If your organization tracks something ProjectXL does not ship with, you can now add it without stepping outside the governed model.
Human-readable codes
This one is almost invisible when it works.
Relationships between project entities previously depended too heavily on internal identifiers. Users should not have to know those identifiers. They know their WBS code, resource code, work package code, activity code.
ProjectXL can now accept those human-readable codes, resolve them to the correct entities, validate the relationship, and explain clearly when it cannot.
The same work added protection against an entire class of data-integrity problems caused by identifier-shaped text being mistaken for an actual reference.
Schedule semantics
The scheduling model continued to mature as real networks exposed cases that simple test schedules do not.
Finish-to-finish chain pull was implemented properly, constraints and predecessors can coexist without one silently erasing the semantics of the other, and network relationships can now be edited in bulk rather than one at a time.
These sound like edge cases until a real schedule depends on them. Then they are the schedule.
Learning inside the product
The in-product learning system also moved from prototype toward production.
There is now a lesson-registry substrate, a first navigation tutorial, and the beginnings of an event trace that allows ProjectXL to understand what a user is actually doing and teach against those actions rather than simply playing a canned sequence.
This work was the subject of an MPUG webinar on embedded learning in early August, which turned out to be a useful forcing function. Nothing exposes the gaps in a tutorial system quite like agreeing to demonstrate it live.
The navigation surface evolved alongside it. The ribbon was reorganized into coherent launch groups, the icon set was rebuilt around a consistent catalog, and navigation now carries enough provenance for the product to understand where a user came from and why.
The part nobody sees
Everything above landed through the same governed build process: each change scoped in a build packet, independently reviewed, verified against its design record, and walked before closure.
The automated suite now runs approximately 7,400 tests in under a minute, on every change.
That discipline is a large part of why five releases could ship in two weeks without the wheels coming off. It is also why this diary can describe what changed with measurements and specific failure modes rather than vibes.
Where this leaves us
At the July update, the claim was that the architecture had started enabling the product.
A month of alpha tested that claim harder than any amount of internal development could have.
The architecture held.
Some of our assumptions did not.
“One workbook, moderate project, cooperative user” is a very comfortable environment in which to build software. August has been about systematically replacing those assumptions with something closer to reality:
however many workbooks, whatever size project, and whatever the user actually does.
That is what an alpha is supposed to expose, and it has made this the most productive month ProjectXL has had.
What’s next
The priorities coming out of August are clear:
-
Continue hardening against tester-reported issues. That queue remains the priority.
-
Finish the change-admission work so ProjectXL recomputes only what genuinely needs recomputing, regardless of project size.
-
Complete the in-product learning system through to the companion experience.
-
Expand the alpha program, get ready for the Beta
If you are running the alpha, keep the reports coming — including the vague ones.
“This felt slow” and “I’m not sure that saved” both became architectural investigations and shipped fixes this month.