Most software conversations with surveyors don’t start with “what can it do.” They start with “how does this actually slot into my day.” That order matters, and most vendors get it backwards.
What are surveyors actually asking about when they ask about “fit”?
They’re not asking whether a tool has enough features. They’re asking whether it changes how they survey a property. Do they still walk the building the way they always have? Do they still capture evidence in the order that makes sense to them on site, or does the tool insist on its own sequence? Is the report they get out the other end something they’d be comfortable putting their name to, or does it read like it was assembled by something that’s never stood in a damp loft at 8am in February?
A feature list answers “what does this do.” Fit answers “will I still recognise my own process once this is in the middle of it.” For a profession built on personal accountability, the second question is the one that actually decides whether a tool gets adopted or quietly abandoned after the trial.
Why does fit come before features?
Because the report is the surveyor’s, not the software’s. Where Survey Report Time Actually Goes makes this point in a different context: the time cost of a survey isn’t the inspection itself, it’s everything that happens afterward when a surveyor has to reconstruct their own reasoning at a desk. A tool that adds a second layer of reconstruction, forcing the surveyor to translate their observations into whatever format the software prefers, doesn’t save that time. It just moves the friction earlier.
This is one thing that’s become obvious the more surveyors I talk to while building Sitarva: nobody wants a tool that asks them to survey differently so the software has an easier time. They want the tool to disappear into the workflow they already trust, and only become visible again when it hands back something useful.
What happens when a tool ignores this?
It gets features surveyors don’t use, and workflow changes they route around. A checklist of capabilities looks impressive in a demo and means nothing if a surveyor still ends up doing the report the old way because the new way didn’t fit how they actually think through a property. That’s the gap between a tool that’s technically capable and one that’s actually adopted.
What is Sitarva, and Why I Built It Differently covers why this shaped the product from the start: it was built around how surveyors already move through a site and write up findings, not around a feature roadmap decided in isolation from that reality.
How should fit actually be evaluated?
Not by reading a features page. By asking what changes on the next inspection. Does the surveyor still control the sequence, the pace, the level of detail per room? Does the tool capture what they say and observe, or does it require them to fit their observations into someone else’s structure first? Does the surveyor still make every judgement call, with the tool doing the capturing and organising around them, not the deciding?
That’s worth checking directly rather than taking on trust. The Features page lays out what the workflow actually looks like in practice, which is a better test of fit than any list of capabilities on its own.
The tools worth adopting are the ones that earn their place by disappearing into work that’s already good. Everything else is just a longer features page.