Construction SaaS Design Notes, Preserving Approved Scope

A contractor prepares an estimate for a project like a driveway. Once the customer approves the materials, quantities, and price, the work proceeds. However, circumstances may change, and the customer might request an expansion. The challenge lies in distinguishing between the original approved agreement and the proposed modifications, while ensuring that the essence of the initial approval is not altered without proper consent.

To address this, separate the working estimate from the approved revision. The working estimate remains editable until the customer submits it. Upon submission, a new revision is created, capturing all line items, units, quantities, prices, and relevant terms at that particular moment. The approval, therefore, refers to this specific revision and not the ongoing editable estimate. This distinction is crucial and should be clearly maintained.

The relationship between approval and the exact content approved must be preserved. A timestamp alone is insufficient for this purpose. If a change occurs later, a proposed revision should be generated, keeping the existing approved revision intact while the new one undergoes review. Historical screens should display the recorded values rather than attempting to reconstruct outdated prices from the current product catalogue.

A clear workflow should be established, incorporating stages such as draft, submitted, approved, rejected, and superseded. Each transition requires authorized actors and well-defined rules. For instance, a project manager might prepare a revision, while a customer or another designated approver would accept it. These roles should be determined by the business agreement.

In scenarios where multiple people are approving and editing simultaneously, it is essential to ensure that approval references the specific revision the approver actually reviewed. If a newer revision exists, the interface should explicitly highlight this difference before proceeding. It is also important to keep project progress separate from commercial approval.

While tasks record operational progress, an estimate revision should document the agreed scope. Completion of tasks should not automatically approve additional work, nor should approving additional work automatically mark it as complete.

When a revision affects a schedule or invoice, the system should make the resulting actions visible. Some changes can be suggested automatically, but changes with contractual or financial consequences require clear ownership. It is advisable to test various failure scenarios before incorporating more automation, including repeated approval submissions, approvals against older revisions, permission changes during review, rejected revisions, and failed notifications.

A failed email should not convert a completed approval into an uncertain state; instead, the screen should clearly indicate the authoritative workflow status.

While revision history adds records and interface complexity, it can also create confusion if the application does not distinctly distinguish between the working draft and the latest approved scope. The design should make these two views easily accessible. My preferred approach is to start with a comprehensive workflow that includes visible revision history, explicit approval, and reliable recovery from failures.

Further automation can be introduced once these rules are well-defined. For developers working on project software, identifying the most challenging approval edge cases in your product, such as Builders Bridge, can provide valuable insights.