If you want to understand why a technology gets adopted in the built environment, do not study the technology. Study who carries the risk.
I came to this slowly. Selling property, then building tools for building inspection, I kept noticing that the arguments which actually moved decisions were almost never about capability. They were about liability, cover, and what happens when something goes wrong. There is usually a party in the background who never appears in the sales process and yet shapes the entire decision.
That party is the insurer.
Why risk carriers drive adoption
Insurance is, at its core, a pricing function applied to uncertainty. An insurer takes on a possible future cost in exchange for a premium, and the premium reflects how uncertain that cost is.
The important word is uncertain, not high. Insurers price predictable risk perfectly well. What they charge heavily for, or refuse entirely, is risk they cannot characterise.
That gives any technology which reduces uncertainty an unusual property. It does not need to prevent anything to have value. It only needs to make the risk more legible. A building whose condition is documented and dated is not necessarily in better shape than one that is not. But it is better understood, and understanding is the thing being priced.
This is why adoption curves in physical industries so often look strange from the outside. A tool sits unused for years despite being obviously useful, then spreads quickly across a whole sector. Usually what changed was not the tool. It was that a risk carrier started asking for it, or started charging differently for its absence.
The three questions that actually matter
When I evaluate whether something we build has commercial weight, I have learned to ask questions from the insurer's perspective rather than the user's.
Does it reduce the frequency of a loss, the severity, or only the uncertainty?
All three have value and they are worth very different amounts. Frequency reduction is the strongest and the hardest to prove. Severity reduction, catching something early so the eventual repair is smaller, is easier to demonstrate. Uncertainty reduction is the weakest sounding and often the easiest to sell, because it requires no claim about the physical world at all, only about the quality of the information.
Is the evidence portable?
This is the one technical teams underestimate. Evidence that only exists inside your product is nearly worthless in a risk conversation. It has to be exportable, dated, attributable, and comprehensible to someone who has never used your software and never will. If a loss adjuster or a lawyer cannot read it without your interface, it is not evidence. It is a screen.
Does it survive a change of owner?
Risk attaches to the asset, not to the account. A record that vanishes when a subscription lapses or a building changes hands has no value in an underwriting decision, because underwriting looks at the history of the thing, not the history of the customer.
What this changes about who you sell to
The uncomfortable implication is that the party who benefits most from a documented building is often not the party you are selling to.
An owner deferring maintenance may prefer that the condition is not documented, for reasons I have written about elsewhere. A facilities manager may see documentation as evidence that could be used against them later. Neither is being unreasonable. Records create accountability, and accountability is uncomfortable for whoever stands closest to the work.
Meanwhile the parties who benefit unambiguously are the ones with no operational role at all. The insurer pricing the risk. The lender assessing the collateral. The buyer's surveyor two years from now. The court, if it ever comes to that.
That gap between who benefits and who buys is, I think, the central commercial problem in this whole category. It explains why adoption is slow despite obvious value, and why it accelerates suddenly when a risk carrier makes documentation a condition of cover rather than a good idea.
What I would not do
There is a tempting shortcut here which I think is a mistake: build for the insurer directly.
The failure mode is that you end up building a compliance artefact. Something whose only purpose is to satisfy a requirement, which means it gets produced as cheaply as possible, resented by everyone who touches it, and quietly degraded until it satisfies the letter of the requirement and nothing else. Plenty of industries have safety documentation that fits this description exactly. It exists. It is filed. It describes nothing real.
The better path is harder. Build something the operational people genuinely want to use, because it makes their week easier, and make the output of that daily usefulness happen to be exactly what a risk carrier needs.
That is a design constraint, not a marketing one. It means the evidence has to be a byproduct of doing the work rather than a separate task performed for someone else's benefit. If capturing the record is a chore laid on top of the job, it will be done badly and the data will be worthless. If it falls out of the job itself, it will be honest, because nobody was performing for an audience.
The summary
In any industry involving physical risk, ask who pays when it goes wrong. That party has more influence over what gets adopted than any buyer, any user, and certainly any product feature.
Then build the thing people want to use anyway, and make sure its exhaust is legible to that party.
Get both right and you are not selling technology at all. You are selling a better price on uncertainty, and that has a market whatever the software does.
I am Issam Fathi, a technology strategist and the product manager of AssetEye by Dronetjek, based in Tetouan, Morocco. I help companies build, adapt, and grow through technology.
