Building with communities, not just for them
Most technology for essential industries is designed in an office, by people who've never done the job it's meant to support. We've been doing it differently — spending real time in the field, and letting what we see change what we build.
There's a particular kind of software that gets built when the people designing it have never done the job it's meant to support. You can usually spot it — the workflow makes sense on a whiteboard, but falls apart the moment someone tries to use it in the actual conditions of their day.
We didn't want to guess our way into that trap, so we don't build from a conference room. Our team spends recurring stretches of time with the people we're building for — not a single polished site visit with a slide deck, but repeated, unglamorous time on the ground, watching routines and sitting with people as they make decisions we'd otherwise only see described in a research report.
A few things became obvious quickly. First, the people we work with are not short on expertise — they're short on time and support. The gap isn't a lack of knowledge; it's the absence of any lightweight way to track, remember, and act on what they already know as things scale past what one person can hold in their head.
Second, trust has to be earned before adoption, not after. We've watched more than one well-meaning app get tried once and abandoned — not because the idea was bad, but because it demanded more setup, more data entry, and more faith than a skeptical first-time user was willing to give for an unproven return. Every design decision we make is filtered through that lesson: does this ask more than it gives back, on day one?
Third — and this one surprised us — the loudest feedback was rarely about features. It was about respect. People can tell, quickly, whether a tool was built by people who understood their work or by people translating an office dashboard into a context they've never lived in. Small things matter: language that doesn't condescend, flows that don't assume literacy in ways that exclude people, defaults that match how a real day actually unfolds.
None of this makes for an easy roadmap. It's slower to build this way — we test ideas with real people before we're confident they're right, and we've thrown out more prototypes than we've shipped. But it's the only way we know to build something that gets used past the first week, by people who've earned the right to be skeptical of promises from outsiders.
We'll keep spending time in the field, not because it's good marketing, but because it's the only reliable source of truth we have. If anything we ship ever stops reflecting what we hear there, that's a signal we've drifted — and one we intend to take seriously.
Read next
Stay in the loop.
Occasional updates on what we're building and learning. No noise.