The Discovery Phase Explained: What US Masonry and Foundation Repair Contractors Get Before a Line of Custom Repair Software Is Written

Start With the Warranty Book Audit

During the software discovery phase, contractors should start with a warranty-book audit. One afternoon can reveal more than a month of requirements workshops.  Pick five completed jobs at random. Choose one from last year, one from five years ago, one from ten, and two from the oldest records.

For each job, assemble the design, as-built depths, both elevation surveys, photographs, permit and inspection records, and original warranty terms. Time the retrieval and note every missing item.

Established contractors often find recent files complete, older ones partial, and the oldest reduced to little more than a contract. That gap exposes liability the business may be carrying without having priced it.

Those findings shape migration effort, registry requirements, and sometimes project urgency. They also give custom software development and custom mobile app development discussions a factual starting point.

From there, discovery can establish what the contractor needs before choosing a trade product, custom layer, or fuller build.

What Discovery Actually Is

Discovery should be a short, paid, time-boxed scoping engagement with a clear end point. Three to five weeks is typical because the warranty audit takes time. 

The engagement should produce documented findings and a costed recommendation, not a proposal that assumes development will follow. It should be contracted separately so the recommendation can still favor a trade product.

The working group should include:

• the owner;
• an inspector;
• a crew lead;
• the person responsible for permits; and
• the warranty administrator handling claims and transfers.

The warranty administrator is easy to overlook. They often know where records fail because they search for files when title companies call.

Discovery should also include direct observation of both an inspection and an installation. Follow the inspection from arrival through proposal. Then observe installation from excavation through backfill.

That matters because field reality can differ sharply from written process documents. An open excavation in bad weather can expose requirements no workshop captured.

The final output belongs to the contractor and should remain usable by any partner, including a trade software vendor.  

What Discovery Should Establish

Discovery should establish five things before a contractor commits to software. Each one tests a different source of cost, risk, or operational weakness.

1. The Warranty Book Position

Count active warranties, identify their formats, test retrieval by address, and estimate what migration would require. The warranty book can represent the largest hidden cost and largest carried liability. Both should be quantified before development begins.

2. The Documentation Gap Analysis

Compare what teams actually capture during inspections and installations with what the written process says should happen. Field requirements should come from observed work, because the muddy reality often differs from the process document.

3. The Elevation Point Problem

Check whether post-work surveys use the same measurement points as the original survey. Discovery often finds they do not, which weakens before-and-after comparisons. That inconsistency is worth correcting even if no software project follows.

4. The Terms Position

Review current warranty terms, older versions, and whether those versions can still be found. Check whether transfers have been honored more generously than the written terms require. Any gap between terms and practice should be surfaced for counsel.

5. The Trade Product Test

Take the requirements to products already built for this trade. Test address keying, version retention, third-party verification, and export as requirements rather than optional details. Third-party verification in particular is web application development work, since the people checking coverage are usually outside the original job. 

The regulatory scope needs definition before commitment.

What the Contractor Receives

Discovery should end with concrete deliverables the contractor can use, even if no custom build follows. The output should make the current risks, options, and next decisions visible.

• Warranty book audit: Count active warranties, assess their condition by era, measure retrieval times, and cost migration separately.
• Documentation gap report: Compare observed inspections and installations with current records, then define the field-capture requirements that follow.
• Elevation survey review: Check whether crews consistently re-measure the same points before and after work.
• Compliance scope: Document operating states, engineering involvement, permit practice, excavation documentation, and cancellation-notice handling. Treat protective systems, competent-person inspection, and utility locating as life-safety requirements, not routine checklist items. 
• Warranty terms review: Work with counsel to examine version history and any gap between written terms and actual practice.
• Trade product test: Classify each requirement as achievable in the product, achievable elsewhere, or genuinely unavailable.
• Defined first release: If building proceeds, document what belongs in the first release and what is deliberately excluded.

Compliance findings are educational, not legal advice. Confirm legal questions with state counsel, design questions with a licensed engineer, and excavation issues with occupational-safety expertise. 

Discovery should also cost three paths. Compare a trade product, a documentation and registry layer beside retained field-service software, and fuller custom development. Each comparison should include ongoing photograph storage and registry preservation.

Several of these deliverables remain valuable even without development.

The Findings Worth Acting On Immediately

Discovery should create value before any software decision is made. Three findings often justify the engagement on their own.

1. Warranty retrieval time: If answering a title company takes days, the contractor has a reputational problem already. The first fix may be better organization, not new software.
2. Elevation point inconsistency: Define the measurement layout once, record it, and reuse the same points after work. That change costs little and immediately strengthens before-and-after comparisons.
3. Terms versus practice: Some contractors honor warranty transfers more generously than their written terms require. That can create expectations that should become a deliberate business decision, with counsel involved where needed.

A fourth issue often appears in the documentation gap. Crews may capture useful evidence that never reaches the office because the transfer path is awkward. Information gets lost between the excavation and the permanent job file. That is often a process problem before it becomes a software problem.

Discovery should surface changes worth making immediately. If nothing actionable appears before development begins, the engagement has not done its job.

Reading the Recommendation

The foundation repair software build vs buy decision should follow the evidence gathered during discovery. The recommendation may favor a trade product, a narrower build, or full custom development. 

1. Implement a trade product when it covers the work and the warranty-registry requirements. Test the registry carefully because superficial demonstrations can hide weaknesses in retrieval, versioning, verification, and export.
2. Build the documentation and registry layer when existing field-service software already handles scheduling, customers, and invoicing well. This is often the most practical finding because the remaining gap sits in inspections, as-builts, and warranty records. It can cost roughly half as much as a full build while targeting the long-term liability directly.
3. Build fully when service mix, branch count, or a franchise-independent competitive position genuinely requires broader control.

One cost follows every path: historical warranty migration. Whether records move into a trade product or custom registry, the existing warranty book still needs findable form. That work should begin early instead of waiting for a development project that may never proceed.

Red Flags in the Conversation

Some warning signs show that discovery is being treated as a sales step rather than an independent assessment.

• Discovery is free and contingent on winning the build.
• A fixed price appears before anyone examines the warranty book.
• The warranty registry is described as a simple records table.
• Nobody proposes observing an installation from excavation through backfill.
• Historical warranty migration is missing from the plan.
• Photograph storage and registry preservation are absent from running costs.
• No trade product is tested against the actual requirements.

Some proposals should end the conversation entirely. Software should never assess crack severity, recommend repairs, determine pier requirements, or generate engineered conclusions.

Urgency tools, expiring pricing, in-room pressure mechanics, or optional cancellation notices are equally unacceptable.

A strong positive signal is much simpler: the partner asks to meet whoever handles warranty claims and transfers. That person usually knows exactly where the record system fails.

Final Thoughts

Discovery should leave a contractor with more than a software recommendation. It should expose warranty conditions, documentation gaps, and migration work.

The five-job audit reveals the liability being carried and the effort required to make historical records usable. Some fixes, including consistent elevation points, should happen immediately.

The longer test is whether warranty records remain findable after staff, systems, or ownership change. That is why retrieval, preservation, and succession matter as much as the initial build.

Discovery may recommend a trade product, a narrower documentation and registry layer, or a fuller custom platform. Whatever the path, the decision should come from evidence, without urgency tactics or pressure to buy.

Before any vendor conversation, pull five random jobs and time each complete warranty-file retrieval. Use those results to decide whether custom development belongs in the next conversation. Learn more about digital transformation solutions from one of the leading AI software companies in the United States.