Config Over Code: An Inspection Reporting Engine the Client Extends Without Us

Inspection reports in construction and engineering vary by project, site and client, and the firms that write them keep needing new ones. For a construction and engineering firm, we built an inspection reporting platform where staff create structured report templates from groups of questions. The key design choice was that new templates need no code changes, so the client can extend the system without calling a developer.

The problem with hard-coded forms

The obvious way to digitise inspection paperwork is to build each report as its own screen. That works for the first few reports. Then the business needs a new variant for a new type of site, then another, and each one becomes a development task with its own cost and delay.

Over time, the software becomes a bottleneck on the business it was meant to help: staff fall back to paper or spreadsheets for anything the system does not yet support.

The design: a report, question and answer engine

Instead of building reports, we built the thing reports are made from. The platform has a configuration-driven engine:

• A report template is made of question groups.
• Each group contains the questions an inspector answers.
• Inspectors fill in answers, which are stored against the report, the question and the project.

Because templates are data rather than code, a new template is created by configuring it in the admin interface, not by writing a new screen.

This is the difference between a form and a form engine. The client does not need us to add the next report.

Tie reports to the real world

A report on its own is not much use. It matters because it is about a specific project, carried out for or with a specific contractor, managed by a specific office.

The platform manages contractors and offices alongside projects, and reports are tied to them. That makes it possible to answer operational questions, such as which inspections are outstanding for a given project or contractor, instead of searching through files.

Review and distribution inside the system

Completed reports go through a review workflow and are emailed to the right people from inside the admin panel. Distribution from the system has two benefits over saving a file and attaching it to an email:

• There is one authoritative copy, with its review status.
• There is a record of what was sent and when.

Role-based access control governs who can create templates, fill in reports, review them and send them.

The stack

The platform uses Laravel with Laravel Nova for administration, Vue for interactive parts of the interface, and MySQL for storage.

When a configurable engine is the right call

A configuration-driven design costs more up front than a handful of fixed forms. It is worth it when:

• The business will keep needing new variants of the same kind of document.
• The people who know what the forms should contain are not developers.
• Reports must be comparable and searchable, not just stored.

It is not worth it for a single form that will rarely change. In that case, a simple fixed screen is cheaper and easier to maintain.

A checklist for digitising inspection or audit paperwork

• Count how many form variants exist today and how often new ones appear.
• If new variants are frequent, model templates, question groups, questions and answers.
• Link every report to the project, contractor and office it concerns.
• Build review status into the report itself.
• Send finished reports from the system, not as loose attachments.

The anonymised write-up is in our work library. A related pattern, turning structured questions into automatic quotations, is described in from questionnaire to quotation. Systems like this are what our business automation service builds.