There is a very simple question people ask us when we talk about inspection software:
“What happens when I lose my connection?”
It is a fair question.
We are based in Norfolk, and we have spent years carrying out inspections ourselves. So we know that mobile connectivity is not something you can take for granted.
You can be in a rural area with little or no signal. You can be in the middle of a town and suddenly have no connection. You can walk into a basement and lose it. You can move from one room to another and go from a strong connection to nothing.
We have actually experienced this ourselves while using an early prototype of our software during a survey in Great Yarmouth. Connectivity came and went as we moved around the property.
That is why offline working isn’t something we have added as a convenience. It is fundamental to how the system works.
Two places for your data
When you log into BrightChecker, there are effectively two places where your survey information can exist.
The first is the main server — the cloud database where your organisation’s data is stored.
The second is the device you are using.
The browser-based application has its own local database, and we use that to store the information required to carry out work when connectivity isn’t available.
So when surveys are assigned to you, you can see them on your device and synchronise with the main system.
When you decide that you are going to carry out a particular survey, you can download the full job.
That is the important point.
You are not simply downloading a webpage. You are committing the job to the device so that the information you need to carry out the inspection is available locally.
That can include the questions and prompts, access information, instructions, previous survey information and other information that has been configured for that job.
Once it is downloaded, you can carry out the inspection without relying on a continuous connection to the server.
What happens while you are working?
This is where things become important.
We don’t wait until the end of the inspection and try to send everything in one enormous upload.
Every individual piece of information is dealt with as it is created.
You answer a question.
You add a note.
You take a photograph.
You record a GPS position.
You add a timestamp.
Each of those things can be placed into a synchronisation queue.
If the server is available, the information is transferred.
If it isn’t, it waits.
The system tries again.
And again.
The queue doesn’t need you to stop working and doesn’t require you to sit there watching an upload screen.
When connectivity becomes available again, the queue can start draining.
That is particularly important in a building where the signal keeps appearing and disappearing.
You might have a connection in one room, lose it in another and get it back ten minutes later.
The inspection shouldn’t care.
Why uploading everything at the end isn’t enough
There is another reason we designed it this way.
Imagine completing a long inspection entirely offline and then trying to upload everything at the end.
You might have hundreds of photographs, videos, answers, notes and other data.
Now you are relying on one connection and one upload session to transfer the entire job.
If something goes wrong, you have a much bigger problem.
We experienced exactly this kind of limitation in earlier software.
The system could effectively reach a timeout before the complete job had been transferred.
Our queue approach breaks that large transaction into much smaller ones.
That makes the process substantially more resilient.
How do you know what has synchronised?
We also wanted the user interface to tell you what was happening.
For example, media can change from an unsynchronised state to a clear synchronised state once the server confirms receipt.
GPS and timestamp information has its own status.
Text and other responses have their own indicators.
Waiting information can be shown differently from information that has successfully reached the server.
The important thing is that the visual status reflects what has actually happened.
But even if you don’t look at those indicators, the data is still sitting safely in the queue until it can be transferred.
Required questions don’t have to stop you
There is another part of the design philosophy here.
If a question is marked as required, BrightChecker can identify the questions you haven’t answered and take you directly to them.
But we don’t force every business to work in exactly the same way.
You can still submit if you decide that is appropriate.
That is deliberate.
Software should help you control your process, not make assumptions about how every inspection business operates.
Offline isn’t a marketing checkbox
For us, offline working isn’t about being able to say:
“Yes, we have an offline mode.”
It is about what happens when the real world behaves exactly as it does.
Signals disappear.
Buildings block signals.
Networks fail.
Phones move between networks.
Inspectors move between rooms.
The system has to carry on working.
That is what we designed BrightChecker to do.