What Construction SaaS Gets Wrong About Their Target Buyer
25 years in the trades, 15 in platform architecture. Most construction SaaS is built by people who've never run a crew — here's what that costs them.
The Context That Most PMs Don’t Have
I’ve been doing concrete, masonry, and hardscapes since 2001. I’ve also been doing enterprise platform architecture since 2010. Most people pick one lane.
Both sides of that equation show up in how I think about construction SaaS products — and why most of them have the same three problems.
Problem 1: The Data Entry Moment Is Designed by Someone Who Has Never Stopped a Job to Input Data
Construction platforms consistently underestimate the cost of data entry at the point of work. It’s not just that it takes time. It’s that stopping to log something on a mobile device while you’re on a roof, in a concrete pour, or under a crawl space is a friction point that gets trained around immediately.
“Just use the app to log materials” only works if the person who designed that flow has felt the resistance of doing it with dirty hands in 15°F weather while a subcontractor is waiting for a decision.
What survives in the field: anything that can be done in under 10 seconds with gloves on, or anything that happens naturally at a moment of rest (end of day, back at the truck). Everything else gets worked around, and then the platform team wonders why adoption is low.
Platform strategy implication: Crew-facing features should be designed for the lowest-friction capture moment, not the most complete data model. You can enrich data back at the office. You can’t get data that was never entered.
Problem 2: The “Owner” Is Actually Three Different Buyers
Construction software often lumps “the contractor” into one buyer persona. In practice, the decision-making unit on a construction software purchase includes:
- The owner/operator (who cares about cash flow, estimates, and whether the software makes them look professional to GCs)
- The project manager or lead (who cares about whether the field crew will actually use it)
- The office manager or bookkeeper (who cares about whether it connects to QuickBooks and produces clean reports)
These three people have conflicting priorities and different levels of technical tolerance. A platform that optimizes for the owner’s demo experience often fails at the PM or bookkeeper level — and field adoption is what determines contract renewal.
Platform strategy implication: Win criteria for each persona need to be explicit in product requirements. SA teams doing pre-sales discovery should map which persona is leading the evaluation and adjust the technical discussion accordingly.
Problem 3: The Platform Assumes Consistent Internet
Rural job sites, basements, crawlspaces, metal buildings — signal issues are not edge cases in construction. They’re Tuesday.
Platforms that require persistent connectivity for core workflows will lose adoption in the field the first time someone loses data on a spotty connection. The offline-first design decision isn’t a nice-to-have for construction SaaS; it’s a field-retention decision.
Platform strategy implication: Offline capability is a trust feature, not a technical feature. Frame it that way in roadmap prioritization discussions.
Why This Matters for Platform Strategy
I’m not making the case that construction SaaS needs to be built by people who’ve swung a hammer. I’m making the case that the product and SA teams closest to the market need enough domain fluency to ask the right questions in discovery — and to know when an answer doesn’t match the reality of how work actually happens on a job site.
That gap is where platforms lose deals they should win and churn customers who should be long-term.
It’s also where I’m most useful.