We all start in spreadsheets.
At first, they do exactly what we need. A cost tracker. A variation register. A simple claim schedule. Then the project grows… and so does the spreadsheet. More users. More formulas. More tabs. More linked files. More logic layered on top of logic.
Over time, it becomes what many teams recognise as the “spreadsheet of all spreadsheets” - the master file that runs everything.
And for it to work, everything has to work.
Sometimes it feels like you need to tap your head and rub your stomach just to update a single value without triggering unintended consequences.
There comes a time when you reach a limit, where every upgrade becomes detrimental - performance slows, transparency weakens, and risk increases.
We reached that point ourselves.
And rather than continuing to stretch a two-dimensional system to manage multi-layered governance, we made a deliberate decision: we would step outside the spreadsheet environment entirely and rebuild from first principles.
Traditional spreadsheet environments allow almost unlimited flexibility, but they offer very little protection -protection from the outside, but more importantly, protection from ourselves.
For example:
● A number that can be entered that exceeds the allowable claim.
● A retention amount can inadvertently surpass its contractual cap.
● A variation can be approved that pushes the contract value beyond its authorised limit.
Unless someone manually identifies the issue, the system accepts it.
Projx was designed to prevent these errors before they occur.
On the surface, Projx’s interface appears simple. A user enters a value into a claim field. If that value breaches a rule- for example, exceeding the “allowed to claim” amount - the cell highlights, an indicator appears, and an explanation is provided. The user cannot proceed until the issue is resolved.
What appears to be a straight forward interaction is, in reality, supported by an extensive hierarchy of calculations and validations.
Behind that single input field sits a structured engine that governs retention percentages, claim ceilings, status dependencies, provisional sum allocations, pay-on-account conditions, and contract limits.
Each rule is categorised either as a hard stop, preventing progression entirely, or as a soft warning - allowingprogression while clearly signalling the user to proceed caution. These rules work together so that any change in one area automatically updates the overall financial position of the contract.
The simplicity of the user experience is deliberate. The complexity has not been removed; it has been absorbed and engineered into the framework (or the so called, “backend”).
Our development process begins not with interface design, but with scenarios.
For every feature, we construct a hierarchy of potential real-world situations. If this condition exists, what must happen? If a claim is submitted post–practical completion, how does retention adjust? If a provisional sum has not been formally converted, what isthe allowable claim position? If a variation pushes the contract value beyond its original ceiling, how does the projected final cost update?
Each scenario is written, tested and validated before any code is produced. We define the calculation logic, map the rule structure, document the validation hierarchy, and develop detailed user stories that trace the lifecycle of a transaction from initiation through certification, payment and reconciliation.
Only once this behavioural framework is confirmed do we prototype the interface and proceed to development.
This methodology ensures that every number entered into the system behaves consistently with contractual reality. Retentions are automatically recalculated as project status changes. Provisional sums cannot be overdrawn beyond approved allocations. Certified amounts flow directly into updated cashflow forecasts, and variations dynamically adjust projected final cost positions across the portfolio. The system continuously reconciles itself in the background.
What users experience as intuitive is underpinned by hundreds of interconnected validation decisions.
To illustrate the depth, consider three common scenarios in project delivery.
When a claim is entered:
● The system verifies contract retention percentage.
● It checks whether the retention applies to the contract sum or adjusted contract sum.
● It calculates retention held to date.
● It ensures cumulative retention does not exceed contract limits.
● It keeps a running balance of the retention held.
● It works out the first and final retention release automatically.
If an entry breaches the allowable threshold, the claim cannot proceed. It’s as simple as that.
When provisional sums are claimed:
● The system checks whether works have been let against the allowance.
● It validates approved let amounts.
● It ensures the claim does not exceed approved provisional allocations.
● It adjusts projected final cost automatically.
This avoids double counting, a commonspreadsheet risk.
For cashflow projections:
● Certified amounts feed forward as‘actuals’ into cashflow projections.
● Projected cost-to-complete adjusts based on forecasts and actuals.
● Variations update projected final cost (PFC) instantly.
Every scenario is validated before it hits the dashboard.
The decision to move beyond spreadsheets was not simply about performance; it was about control.
When governance relies on manual checking, the system depends on human memory and vigilance. In high-pressure environments, particularly during payment cycles or Project Control Group meetings, that margin for error becomes increasingly exposed.
By building our own rule architecture, were moved those structural vulnerabilities. We were no longer constrained by thelimitations of a file-based system. Instead, we were able to design validation logic that mirrors the realities of project delivery, incorporating layered approvals, financial thresholds and forecasting behaviours directly into the platform.
The result is not merely centralised information or streamlined reporting. It is a framework that anticipates common industry failure points and embeds safeguards against them.
Projx is not simply a digital interface for property development and capital works projects. It is a codified governance structure shaped by real industry experience. The validation rules, cascading calculations and scenario testing are derived from the recurring challenges we and our peers have faced: over payments that required recovery, provisional sums that distorted forecasts, reconciliations that consumed days, and reporting discrepancies identified too late.
Rather than relying on users to remember every contractual nuance, the system remembers for them.
Good technology does more than present data attractively. It provides structure, enforces discipline, and supports decision-making through embedded intelligence. It allows project professionals to focus on strategic outcomes, such as delivery certainty, cost control and stakeholder alignment, rather than manual verification and risk containment.
Projx’s interface may appear simple. Theengineering beneath it is anything but.
Being able to absorb complexity so that users experience clarity is the core advantage of Projx, and the reason we believe purpose-built technology represents the next step beyond the spreadsheet era.
© 2026 Copyright. All Rights Reserved.
