If your site team dreads filling in records, the process is wrong

28 Apr 2026 · 0 min

Watch on YouTube

0:29

In this segment, the speaker explains the origin of Rail Diary and the pivotal lesson learned from the company's CTO, Paul, who previously ran the digital agency Gather Digital. The core argument is that data entry should not be modeled as filling tables—tables are for interpreting data, not capturing it. For on‑site construction teams, simply porting a spreadsheet to a tablet is ineffective. Instead, the solution is to provide a structured, workflow‑driven mobile interface that accommodates the harsh, rainy conditions workers face, ensuring they can capture accurate data easily and reliably.

So when I started Rail Diary as it was, and I met Paul, who's our CTO and ran a digital agency called Gather Digital at the time, the first thing I learned was the best way to enter data is not in a table. That's not how you enter data. That's how you interpret it or read it. But when you're asking someone to capture data on site, it's not just about going, take this fancy spreadsheet that QS has built and put it on an iPad or put it on a tablet. It's about giving it structured workflow and making it easy for that person in orange in the pouring rain to capture that data correctly.