The Honest Cost of Building Your Own Inspection Tracking System

Nobody decides to build software. They decide to fix one thing.

The origin story is identical everywhere. A technician's certification lapses and a job has to be re-shot. The QA manager builds a spreadsheet. Six months later the spreadsheet has a second tab for equipment, then a third for jobs, then a macro. Somebody's nephew who codes converts it to Microsoft Access over a long weekend. At no point does anyone approve a software project, allocate a budget, or write down what the system is supposed to guarantee. That is the problem. The system became infrastructure without ever being treated as infrastructure.

The tell is the day you cannot run the business without it. Ask when the file was last backed up, who has edit rights, and what happens if it corrupts on a Tuesday morning with four crews mobilised. If those questions produce silence, you already own a production system. The decision in front of you is not whether to build — you built. It is whether to keep maintaining what you built or move the load onto something maintained by someone else.

What Access actually gives you, and where the ceiling sits

Access is a legitimate tool and deserves a fair hearing. It gives a small firm relational tables, forms, and reports without a developer on staff, and it will handle a few thousand jobs without complaint. Microsoft publishes the limits: a database file caps at 2 gigabytes minus the space needed for system objects, a maximum of 255 concurrent users, and 32,768 objects in a single database. For a firm running one office and ten technicians, none of those numbers is close. The ceiling is not the problem in year one.

The ceiling becomes the problem when you attach anything heavy. Radiographic images, scan files, and PDF reports stored inside the database eat the 2 GB allowance quickly, and the standard fix — storing file paths instead of files — means your job record and your evidence now live in two places that can drift apart. The 255-user figure is theoretical for a file-share deployment; contention and corruption appear far below it once several people write at once over a VPN. Firms hit the practical ceiling years before the published one.

There is a clean upgrade path — move the tables to SQL Server and keep Access as the front end. It works. It also converts your weekend project into a system with a database administrator, a licensing cost, and a backup regime, which is the moment the honest build-versus-buy comparison should have happened. Compare that fully-loaded position against purpose-built inspection software before you commit another year of internal time.

Maintenance is the bill. The build was the deposit.

Construction feels like the expensive part because it is the visible part. The software-engineering literature says otherwise: maintenance consumes 80 to 90 percent of a system's total lifecycle cost (Ulziit et al., 2015). Applied to an in-house tracker, that means the four weekends spent building it represent roughly a tenth of what the thing will cost you. The remaining nine tenths arrive as interruptions — small, constant, and impossible to schedule.

Maintenance in an inspection firm is not abstract. A client changes the report format. A new method gets added to the scope. The written practice is revised and the certification rules in the database no longer match. A technician joins from a firm using a different level nomenclature. Each of these is a database change, and each has to be made by the one person who understands the schema, between his actual job of running inspections.

Buying does not remove maintenance. It relocates it. The vendor absorbs the platform work — the security patches, the database upgrades, the format changes — and you keep the configuration work, which is the part that genuinely requires your knowledge. That reallocation is the entire economic argument, and it holds whether you evaluate us or anyone in the reporting software market. Judge vendors on what they take off your plate, not on feature counts.

The bus factor: what the week after his resignation looks like

Every in-house system has a bus factor, the number of people who can be hit by a bus before the system becomes unmaintainable. In inspection firms it is almost always one. The builder knows why the status field has five values instead of four, why one query excludes a client, and which report is safe to modify. None of it is written down, because it was never a project with documentation as a deliverable.

When he leaves, the system does not stop. That is what makes it dangerous. It keeps running, keeps producing numbers, and nobody can verify those numbers are still correct. A certification rule that silently stopped firing in March produces a clean dashboard in June. The failure is invisible until an auditor samples a job from April and finds a technician who was out of date.

Test your own exposure this week. Pick one calculated field — the one that decides whether a technician is eligible for a method — and ask somebody other than the builder to explain how it works and show you where the logic lives. If that takes more than ten minutes, the system is undocumented, and undocumented is the same as unauditable. Run the test on a Monday, before anyone can prepare.

Audit defensibility: a database has to prove it was not edited

This is where home-grown systems fail hardest, and it has nothing to do with features. ISO 9001:2015 clause 7.5.3 requires documented information to be controlled — protected from unintended alteration, with obsolete versions prevented from unintended use. ISO/IEC 17025 goes further for testing laboratories, with a technical records clause at 7.5 that requires records to show the original observation and any amendment, including who made it and when.

An Access file on a shared drive satisfies none of that by default. Anyone with the network path can open it, change a result, and save. There is no user identity, no timestamp, no before-and-after. You can build all of it — audit tables, triggers, a login screen — but now you are building compliance infrastructure, and you have to prove it works, not just assert it. That proof is itself a deliverable an auditor will test.

Regulated clients raise the bar again. OSHA's process safety management rule requires each inspection and test on covered process equipment to be documented with the date, the name of the person who performed it, the equipment identifier, a description of the test and the result. Your system has to reproduce that record for a job three years old, on demand, in a room with an auditor. Run a program audit and gap assessment against your current tracker before a client runs one for you.

The integration tax nobody puts in the business case

The in-house tracker holds job data. Accounting holds money. Nobody builds the bridge, so somebody re-keys. In a fifteen-technician firm that is a day a week of transcription between the job record and the invoice, plus the errors transcription creates — a job marked complete that never got billed, an invoice for a re-shot job the client refuses. Neither error is discovered in the month it happens.

The same gap opens between the tracker and the field. Technicians capture on paper or a phone, then someone types it in. Every transcription step adds a delay between the inspection and the record, and audit defensibility depends on records being contemporaneous. A week-old typed record of a Tuesday inspection is a weaker artefact than a signed capture from the day.

Purchased systems close both gaps as a matter of course, which is why a direct QuickBooks connection shows up as a line item in serious evaluations. It is unglamorous, and it is where the recovered hours actually sit. Count the transcription steps between a technician finishing a job and the invoice leaving your office. Three steps is normal in a firm running an in-house tracker. One is achievable when the job record, the report and the accounting entry share a single source, and every step removed is an error class removed with it.

Three situations where building genuinely wins

First: your process is a real differentiator. If you have a proprietary acceptance methodology, a client-specific data model no vendor supports, or an analysis routine that is the reason clients hire you, build that. Build only that, and buy the certification, calibration and reporting scaffolding around it. Custom where you are unique, standard where you are not. The mistake is inverting it — building the scaffolding because it is easy and buying nothing.

Second: you already have permanent development capacity. A firm with two salaried developers and a product owner can carry a system, because maintenance has an owner with a job description. The failure case is the firm that has one developer's spare time and treats it as free capacity. Spare time is not a maintenance plan. Ask one question to test it: whose annual review includes uptime of this system? If nobody's does, the capacity is imaginary.

Third: you need a thin layer, not a system. A dashboard reading from a purchased platform's API, a client portal, a custom export — these are small, replaceable, and low-risk. Build at the edges. The core records that carry legal weight — certification status and calibration state — belong in something maintained by an organisation that will outlive one employee. That split lets you keep every piece of custom logic you value without owning the parts an auditor will test.

How to settle it in two weeks

Week one, inventory. List every spreadsheet, database and calendar that holds a record the business depends on. For each, name the owner, the last backup, and what breaks if it disappears. Most firms find between six and twelve. The count alone ends the debate, because nobody believes they have twelve systems until they see the list. Write the list on one page and circulate it to the partners.

Week two, price the real comparison. Against building, put a named maintainer, a documented hours-per-month allocation, and the cost of a rebuild when that person leaves. Against buying, put configuration effort, data migration and the internal time to run the change. Then test both against one question: can you produce, in five minutes, the complete evidence chain for a job you closed two years ago?

Whichever way that question falls is your answer. A firm that can produce the chain in five minutes has a working system and should stop debating. A firm that cannot has a decision to make, and the decision is about where the maintenance burden sits, not about software features. If you want the comparison run by somebody who has watched both outcomes play out in inspection firms, ask for a working session and bring the inventory list.

Request a consultation