Map first. Test before you buy. Build only the gap.
The method is built for three things: a software decision you can check, a rollout that does not stop work, and a system you can run without us.
The steps
Steps 1 to 3 are process mapping. Steps 4 to 6 are software selection. Steps 7 and 8 are setup and onboarding.
-
1. Discovery
Questions you can answer in an afternoon: how many jobs, invoices and subs you run, what growth is funded rather than hoped for, what the current mess costs, whether your process is written down or lives in people's heads, who will look after the system, and what is driving the timing.
-
2. Map how work and money move
We trace how jobs, POs, invoices and payments move between people, spreadsheets, inboxes and apps. It is read-only: nothing is changed. Each handoff is marked by what carries it: a person, an email, a system, or nothing.
-
3. Requirements blueprint
We write down what the system must do before anyone shops: one job identity, four money stages, the count-once rule, delivery order, who sees prices, the audit trail, how your job numbers move over, a test environment and handover.
-
4. Acceptance tests
Your messy cases become plain-language tests: three POs and a short-paid invoice on one job, a partly finished job, one vendor bill split across several lots, a sub invoice with a backcharge.
-
5. Coverage matrix and paths
Each product on the list is checked against every requirement: covered, partial, not covered or not confirmed, with the evidence level stated. Options come as paths with plain trade-offs.
-
6. Live demos, scored
Vendors run your tests live. We score what they show, not what the brochure says. A failed test defines the custom work, if any is needed.
-
7. Staged setup and onboarding
Configure, test in a sandbox, pilot on a few jobs, hold to verify, then roll out team by team. Old and new run side by side. One change at a time. Every change reversible.
-
8. Handover
The goal is that you run it without us. Everything needed to do that is written down and handed over.
Rules we work by
- Nothing in your systems changes during discovery.
- Measure a starting point before promising any improvement.
- Leave unclear records for a person to decide. Do not guess.
- Run old and new side by side. No hard switch-over.
- One change at a time.
- Every change can be undone.
- Compare against the live copy before changing it. Check it again after.
Sample deliverables
By the end of an engagement you hold eight things. Three of them are drawn below with made-up data.
- Discovery summary. Your answers to the discovery questions, in one place.
- Requirements blueprint. Job identity, money stages and delivery order.
- Acceptance tests. Your messy cases, written as pass-or-fail scenarios.
- Coverage matrix. Every requirement against every product, with evidence levels.
- Options memo. Paths with plain trade-offs.
- Demo scorecard. What each vendor showed against your tests.
- Rollout plan. Stages, gates and who is involved.
- Operator guide, role manuals and change log. What you need to run it without us.
Sample A: Requirements blueprint, excerpt
Requirements blueprint (excerpt)
- 1. Job identity. Every record carries all four:
- Customer:
- Sample Builder
- Community:
- Sample Community
- Lot:
- 25
- Job:
- 1042
- 2. Money stages. Each stage is its own record. None overwrites another.
- Authorized: purchase order received
- Completed: work recorded in the field
- Billed: invoice sent
- Paid: payment received and matched
- 3. Count-once rule. Every amount is counted once. A shared bill or payment is split by allocation, never copied.
- 4. Who sees prices. Office roles see prices and costs. Field roles see the job, lot, scope and what to record.
- 5. Delivery order.
- Jobs and purchase orders
- Completed work, billing and quality checks
- Subcontractor onboarding and pay
- Purchasing and scheduling
- Vendor bills and owner reporting
Deferred items are listed by name, with the reason.
Sample B: Acceptance-test card
Acceptance test 03
Scenario: Job 1042, Lot 25, Sample Builder: three purchase orders and one short-paid invoice
- Setup: Sample Builder sends three purchase orders for Job 1042. The crew completes all three. Three invoices go out. Sample Builder pays one of them short.
- The vendor enters, live, in the demo:
- The three purchase orders against Job 1042
- Completed work against each purchase order
- One invoice per purchase order
- The payments, including the short one
- Passes if: The system shows 3 authorized, 3 completed, 3 billed, 2 paid in full and 1 paid short, and the short-paid invoice appears on an open-items list without anyone building a spreadsheet.
- Result: PassFail
- Evidence: Seen in live demoVendor documentationNot yet shown
Sample C: Coverage matrix, excerpt
Coverage matrix (excerpt)
| Requirement | Product A | Product B | Product C |
|---|---|---|---|
| One job ID: customer, community, lot, job | Covered (D) | Partial (V) | Not confirmed (P) |
| Four money stages kept separate | Partial (D) | Covered (D) | Not covered (V) |
| One vendor bill split across lots | Not confirmed (P) | Covered (D) | Partial (V) |
| Crews cannot see prices | Covered (D) | Not confirmed (P) | Not covered (V) |
| Phone screens in Spanish | Partial (V) | Not covered (D) | Not confirmed (P) |
Covered. Partial or needs setup. Not covered. Not confirmed.
D = seen in live demo. V = vendor documentation. P = public pages only.
Every cell is a question for the demo, not a finding.
Questions about the method
How do I avoid buying the wrong construction software?
Write your requirements before you watch a demo, using your own messy cases: a job with three purchase orders, a short-paid invoice, a vendor bill split across lots, a backcharge. Make each vendor enter those cases live. Score what they show, not what the brochure says. Where a product fails, you have found the gap.
What should I ask in a construction software demo?
Ask the vendor to run your scenarios, not theirs. Bring written cases from your own jobs and have them entered live. Then ask who can see prices, how the audit trail works, how your existing job numbers move over, whether there is a test environment, and how you get your data out if you leave.
What is a requirements blueprint?
A requirements blueprint is a plain-language document that says what your system must do before you shop for it. It sets one identity for every job, the stages money moves through, who sees what, what is deferred, how old data migrates and how the system is handed over. Every product is measured against it.
What is an acceptance test in software selection?
An acceptance test is a real scenario the software must handle before you buy it, written in plain language. For example: Job 1042, Lot 25, Sample Builder, three purchase orders and one short-paid invoice. The vendor enters it in a live demo. It passes or fails, and each failure defines custom work.
Who in my company should run the new system?
Name one owner for the system before you buy, usually the office manager or whoever already keeps the records straight. They handle users, settings and small changes, and they are the first call when something looks wrong. If nobody has time for that role, count it in the choice, because unowned systems decay.
Want to see where your process stands?
Email a few lines about your trade, what you use today and what is breaking. We will start from there.