David Ward‘s journey from technology executive to construction tech founder wasn’t driven by industry expertise; it was driven by an urgent call during the pandemic. His experience turning Safe Site Check in from an emergency solution into a widely adopted platform reveals a counterintuitive truth: construction’s digital resistance stems not from technology aversion but from deployment complexity. We explore how eliminating user management, training requirements, and IT involvement transformed endless pilots into immediate adoptions.
About David
David Ward is CEO and Founder of Safe Site Check In LLC, a digital jobsite management platform launched in 2020. With over 40 years in technology, having launched and grown several successful companies, Ward brings a unique perspective to construction tech as someone who “didn’t come from a construction background except as a programmer at Bechtel forty years ago.” His approach to building Safe Site Check In, starting with clear customer requirements and ruthlessly simplifying deployment, reflects decades of experience in technology management, cloud engineering, and solving real-world problems through innovation.
Introduction
“Gotta make it simple. Gotta make it easy. Because building is already complicated and risky enough without putting another project, a technology project, into that building project.” David Ward
In construction technology, a graveyard of promising solutions exists, having died a slow death in the “pilot purgatory,” an endless cycle where construction companies run prolonged pilots that never convert to full adoption. For most software founders, these extended evaluation periods represent a fundamental misunderstanding of what construction buyers actually need. But David cracked the code, turning Safe Site Check In from a pandemic emergency solution into a widely adopted platform by discovering a deceptively simple formula: requirements + simplicity = successful adoption. Construction’s barriers weren’t about features or functionality; they were about deployment complexity, obscuring clear requirements.
The revelation behind requirements
David’s journey began not as a construction insider but as a seasoned technology executive who received an urgent call from a construction company friend during the pandemic. “I have three dozen job sites, and I don’t want to collect paper from every one of them,” his friend explained. Within eight weeks, David’s team built an MVP. Within ten weeks, they cashed their first check. But the real education began when the pandemic ended and they had to evolve beyond emergency compliance.
“We knew the pandemic would end, so we kept adding in conversations with superintendents and safety managers in particular, and project managers,” David explained. They employed a lean development approach, following Eric Ries’s methodology of building, measuring, and learning through customer feedback, which revealed something counterintuitive about the relationship between construction and innovation.
The construction industry loves new technology, just not digital technology. This distinction reflects what David calls a “cultural split” between the architecture and engineering (A/E) side and the construction (C) side.
“There’s developed almost a cultural split between the managers in the field and the headquarters of contracting companies,” David explains.
The headquarters utilises digital technology encompassing project management platforms, BIM systems, and design software. But field managers operate under a different logic: “Building anything is complicated and risky enough without putting another project, a technology, into that building project.” “If there’s a new sawzall or nail gun or something, they can get excited about that. But not so much digital,” David observes. The difference lies in tangibility and immediate utility. A new power tool delivers obvious benefits: it cuts faster, drives deeper, lasts longer. Its value is measurable in physical output—boards cut per hour, nails driven per minute.
Digital technology operates differently. Its benefits are abstract: data capture, process optimisation, and compliance tracking. These improvements exist in spreadsheets and dashboards, not in the concrete and steel that construction workers see taking shape daily. “Tools are physical,” David explains.
“One of the things that I’ve learned about the job site in construction is that people whose careers are at the job site, their whole mindset and job satisfaction come from building with molecules and tools. Stuff that’s actually physical, not digital.”
This insight reveals why construction professionals can simultaneously embrace sophisticated machinery while resisting project management software. A crane operator using GPS-guided systems to place steel beams experiences technology-enhancing physical construction. A superintendent entering daily reports into multiple digital platforms experiences technology as administrative overhead divorced from the actual building process.
This insight became the foundation for everything that followed. If field workers were fundamentally oriented toward physical tools and processes, any digital solution had to bridge that gap with consumer-level simplicity. The requirements weren’t technical; they were cultural and operational in nature.
Eliminating the adoption killers
Traditional construction software fails because it creates barriers to adoption rather than removing them. David’s approach was methodical: identify every friction point that extends pilot periods and eliminate it. The result was a philosophy of “easy to buy, easy to deploy, easy to pay for.”
The most radical decision was eliminating user management. “Construction companies with all the subcontractors and visitors stuff, they do not want to do user management at all,” David discovered. “So we eliminated that from our business model as well. You pay based on the number of check-ins per month per site. Not based on the number of users.” This single change removed one of the most significant deployment obstacles: the administrative overhead of managing user accounts across constantly changing project teams.
Training became equally ruthless in its simplicity. “You print out a QR code poster and just put it up at the job site,” David explains. “Don’t have to do any training at all.” The pandemic had inadvertently solved a massive education problem by teaching everyone what QR codes were and how to use them. Safe Site Check In leveraged this universal literacy to create a truly zero-training deployment.
The restaurant bill analogy
The most telling design decision came from understanding who actually shows up on construction sites. “In many, if not most cases, there’s more vendors, subcontractors, and visitors on a job site than employees,” David notes. This led to what he calls the “restaurant bill analogy”: how could you pay for your restaurant bill using any device? The answer is that it has to be a web page, not a downloadable app.
“That can’t be an app to download because anybody can show up in a restaurant. And as it turns out, anybody can show up at a construction site, too.” This insight drove the decision to build primarily as a web app, eliminating app store downloads, device compatibility issues, and IT approval processes. “You never know who’s gonna show up and with what device. It’s gotta be click and go.”
The technical implications were profound. By choosing the web over native apps, Safe Site Check In eliminated the need for IT department involvement for most customers. We largely eliminated any need for IT services. We take care of information security. We take care of data storage. We take care of data protection in general. So the IT department doesn’t have to.”
This pattern of web-first deployment, solving enterprise access problems, extends beyond construction. Tore Hovland, founder of NovaRender, faced a similar barrier in the oil and gas industry: expensive well scans costing hundreds of thousands of dollars sat unused because clients needed memory sticks with both the data and the application, and weren’t allowed to install either. “We would bring them a computer and just give them a laptop,” Tore recalls, describing how his team literally shipped hardware to work around software installation barriers. His solution mirrored David’s: move everything to cloud-driven web apps so users could “just send the customer a link and they could go into web pages.” Different industries, same insight: eliminate installation friction entirely.
Converting pilots to adoption
The difference between a two-week pilot and a ten-month pilot isn’t about product complexity; it’s about clarity of requirements. David discovered that successful pilots focus on specific compliance needs rather than broad operational improvements. “The test is not whether the project is successful,” David explains. “The test is whether those specific general requirements are being met.”
This requirement-focused approach is practical because it provides customers with clear success criteria. Projects with high compliance requirements, such as healthcare structures, schools, and laboratories, drive adoption because they create non-negotiable digital needs.
The business model alignment supports this approach. Safe Site Check In positions itself within general requirements rather than as specialised software, competing for overhead allocation rather than capital expenditure. “We positioned ourselves as a subcontractor,” David explains, “but not in a category that is typically bid or estimated. We’re all lumped into the general requirements: everything from parking to porta-potties to project management software.” This strategic positioning works because “general requirements generally go into the overhead factor. And to be competitive in a construction bid, you want your overhead factor to be as low as possible.”
By eliminating multiple general requirements through a single, comprehensive solution, we can demonstrate measurable value in access control, security, safety management, compliance reporting, and workforce data collection.
“We did a workflow analysis of doing check-in on paper versus using our app,” David notes. “We can credibly say you’ll save $2 on every check-in.”
However, the real impact often extends beyond these calculations. “The easiest pitch is when it’s a customer using project management platforms like Procore,” David explains. “If they didn’t have our solution, they’d have to type in the workforce data every day. Nobody wants to pay a project manager to type in manpower data.” For safety managers, the value is even clearer: “That guy knows the cost of collecting paper and typing it into a system; they don’t want to have anything to do with it.” While they maintain an ROI calculator, David notes that “most of the time, they take our word for it. The reason they buy is because they have a requirement to do the things that we do digitally.”
The generational shift
But David’s success revealed something deeper than just solving deployment problems. As he watched, he noticed a clear pattern in which customers adopted the fastest.
“Your best customers in the sense of their ability to adopt digital are run by the son or the daughter of the founder. Who’s between 35 and 45 years old, and has younger managers who grew up with the Internet and now use mobile devices in their everyday life.”
This demographic insight revealed something profound about the construction industry’s digital transformation. Multiple CEOs gave David the same advice when he started cold-calling the industry: “Don’t talk to anybody over 50.” “Which was kind of insulting because I’m over 50,” David laughs, “but I think they were right.” The construction industry’s family-owned structure is experiencing a unique transition moment where digitally fluent successors inherit businesses built on analog processes.
“That generation has been successful in its way, but many of them are close to retirement and really don’t want to be part of the digital change,” David observes. The companies run by the founding generation’s children represent the industry’s digital future, but only for solutions simple enough to work across generational lines. This requirement drove Safe Site Check In‘s design philosophy: create tools that leverage the digital fluency of younger managers while remaining comprehensible to experienced field workers.
Understanding this generational divide shaped how David approaches customer implementation. Like Steve Jobs’s obsession with elegant simplicity, David coaches customers toward restraint rather than feature accumulation. “We help them to accomplish in the simplest possible way. The main business issue with the trades is to ensure they are allowed on-site and then get them to work as quickly as possible. So it can’t be anything complicated.”
This philosophy mirrors his understanding of how people actually interact with complex tools. “I’m reminded about the tens of thousands of features and functions in Microsoft Word, for example. And the fact is, most people only use 20 of them or something like that.” Rather than overwhelming customers with capabilities, we grow functionality over time while advising customers to keep initial implementations as simple as possible.
Requirements-driven simplification
David’s success highlights a key principle for construction tech adoption: solving precise requirements through radical simplification, not flashy features or complex implementations. The value proposition isn’t about replacing human expertise; it’s about eliminating administrative friction that prevents people from doing their actual jobs.
“Software in the field has to be consumer-level of usability,” David emphasises. “And that means the infrastructure it uses has to meet the same standard.”
This standard is critical in construction because field workers lack time for complex tools, connectivity can be unreliable, and anyone might show up on site with any device. The consumer standard applies to everything: user interface design, deployment models, business models, and support requirements.
The construction industry’s resistance to digital adoption isn’t about technology aversion; it’s about the complexity of deployment obscuring precise requirements. When David eliminated user management, training requirements, app downloads, and IT involvement, pilot purgatory disappeared. The lesson for construction technology founders is clear: identify the real requirements, then ruthlessly eliminate everything that doesn’t directly serve them.
Construction companies don’t need more features. They need a simpler deployment. They don’t need sophisticated software. They need consumer-grade tools that meet enterprise standards. Most importantly, they don’t need education about the benefits of technology; they need tools that demonstrate value through immediate simplicity rather than promised sophistication.
David’s framework is: easy to buy, easy to deploy, easy to pay for and provides a blueprint for breaking pilot purgatory across construction technology. However, the deeper insight transcends construction: in industries resistant to change, clarity consistently beats complexity.
“Clear requirements, simple implementation,” David reflects, summarising his five-year journey. “These two things match perfectly, and they are the enabler.” For product builders entering construction or other traditional industries, the path forward is clear: deliver precisely what’s needed, in the simplest way possible.
For founders building in construction or other traditional industries, the challenge is straightforward: simplify relentlessly, focus on real requirements, and eliminate friction at every step. In an industry built on physical precision and practical solutions, this clarity of purpose not only drives adoption but also drives inevitable success.