建築 SaaS 設計筆記：如何在保留已批准範圍的同時處理變更

An estimate changes, a customer approves it, and the project continues. What should happen when someone edits that estimate a week later.

This is a design discussion for construction software. It describes a proposed approach, rather than a claim about the current Builders Bridge implementation. I am Tilak Raj, founder of Brainfy AI Inc., the company building Builders Bridge.

Start with a concrete example.

A contractor prepares an estimate for a driveway. The customer approves the materials, quantities, and price. Later, the customer requests a larger area. The team needs to see both the approved agreement and the proposed change.

A single editable record makes that distinction difficult. Overwriting the quantity can change the meaning of the approval without anyone approving the new amount.

Separate the working estimate from the approved revision.

I would keep a working estimate editable until it is submitted. Submission would create a revision containing the line items, units, quantities, prices, and relevant terms at that point in time. Approval would refer to that specific revision.

The important relationship is between the approval and the exact content being approved. A timestamp on an editable estimate is not enough to preserve that relationship.

A later change should create a proposed revision. The existing approved revision remains available while the new revision moves through review. Historical screens should display the recorded values, rather than reconstructing an old price from a current product catalogue.

Make the transitions explicit.

A small workflow could use draft, submitted, approved, rejected, and superseded states. Each transition needs an authorized actor and a clear rule. A project manager might prepare a revision, while a customer or another designated approver accepts it. Those roles depend on the business agreement.

Consider two people approving and editing at the same time. A practical acceptance rule is that approval must reference the revision the approver actually reviewed. If a newer revision exists, the interface should explain that difference before continuing.

Keep project progress separate from commercial approval.

Tasks can record operational progress while an estimate revision records agreed scope. Completing a task should not silently approve additional work. Approving additional work should not silently mark that work complete.

When a revision affects a schedule or invoice, the system should make the resulting action visible. Some changes can be suggested automatically. Changes with contractual or financial consequences need clear ownership.

Test the failures before adding more automation.

I would test a repeated approval submission, an approval against an older revision, a permission change during review, a rejected revision, and a failed notification. A failed email should not turn a completed approval into an uncertain state. The screen should show the authoritative workflow status.

I would also test exports. An exported estimate should identify its revision and approval status so that a downloaded file can be understood later.

The tradeoff.

Revision history adds records and interface complexity. It can also create confusion if the application does not distinguish the working draft from the latest approved scope. The design should make those two views easy to find.

My preferred starting point is one complete workflow with a visible revision history, explicit approval, and reliable recovery from failures. More automation can follow after those rules are clear.

For developers working on project software, which approval edge case caused the most difficulty in your product.

Builders Bridge. https://buildersbridge.ca?utm_source=devto&utm_medium=community&utm_campaign=buildersbridge_engineering

Disclosure. This article was generated with AI assistance on behalf of Brainfy AI Inc. It presents design recommendations and does not report verified production results.