Shipping Onsight: lessons from building workforce intelligence at field scale
Onsight is a workforce intelligence platform we built end-to-end at Hexcore — admin dashboard, native mobile app, exception queue, and the OpsIQ AI command layer. Here's what we learned shipping a four-surface product to teams operating in tough field conditions.
Field workforce software is a deceptively hard problem. The user is on a phone in a place with bad reception. The stakes are real money — payroll, client billing, compliance. The data must hold up under audit. The interface must work for a manager who has 11 minutes between shifts to figure out who didn't check in.
We spent 14 months shipping Onsight — a workforce intelligence and compliance platform for teams that operate on-site. Four surfaces: admin command center, mobile app, exception action-queue, and OpsIQ, an AI command layer that turns attendance events into explanations managers can act on.
Here's what we learned.
The architectural decision that mattered most: policy as data
The default way to build attendance software is to encode the rules in application logic. "Check-in is valid if user is within 200m of an approved site, during working hours, on a trusted device."
This works until the second customer asks for a slightly different rule. Then you have if-statements forever.
We made tracking policy a first-class data model instead. Every check-in is evaluated against a policy graph: working-hour windows, geofence boundaries, trust-signal thresholds, exception types, all stored as data, edited via the admin UI, versioned per-customer.
This took 3 weeks longer upfront. It paid back within 4 months when we needed to support Enterprise-tier biometric controls, Business-tier auto-checkout, and Free-tier basic geofencing — all from the same engine, no branching logic.
Lesson: when you're building B2B SaaS that will end up serving multiple plan tiers, design the configuration model before the feature model. The feature model is downstream.
Offline-first wasn't a feature, it was the architecture
The mobile app couldn't assume connectivity. Many on-site workers are in basements, parking garages, rural sites, or areas where the mobile network is intermittent. A check-in that fails because the device couldn't reach the server is unacceptable.
We built the mobile app offline-first from the ground up:
- All attendance events captured locally to an encrypted SQLite store
- A reliable sync engine with exponential backoff and conflict-free replicated structures
- Server-side replay-protection so a 6-hour-delayed check-in is still verifiable
- Clear UI affordances showing sync state — workers know what's still pending
The temptation in mobile development is always to treat offline as an error state. For field workforce software, offline is the normal state. Building from that assumption changes every design decision downstream.
Trust signals: layered, not gated
A naive geofence implementation says: "you're within the boundary, you're in. Otherwise, you're not." This produces two failure modes:
- False positives: GPS spoofing apps. Workers checking in from home.
- False negatives: GPS drift at building edges. Legitimate workers locked out.
We layered trust signals instead of treating them as a binary gate:
- Geofence accuracy (raw GPS dilution + cell tower triangulation)
- Device integrity (rooted/jailbroken detection, attestation API where available)
- Behavioural patterns (does this check-in fit historical norms for this user?)
- Optional biometric confirmation on suspicious events
Each check-in gets a trust score, not a binary verdict. Policy then decides what to do with low-trust events: auto-approve, require biometric, surface to manager queue. Customers can tune the thresholds.
This single design decision dropped customer-reported false positives by ~70% compared to a binary geofence and gave Enterprise customers the levers they needed for high-compliance use cases.
OpsIQ: AI as a command layer, not a chat bubble
The temptation with AI features in 2026 is to bolt a chat box onto your product and call it AI. We resisted.
OpsIQ is structured around the manager's actual workflow: "what changed today that I need to know about?" It produces:
- A daily morning brief: sites covered, exceptions surfaced, anomalies relative to baseline
- Explanations on individual exceptions: not just "Sam missed checkout" but "Sam's checkout was 47 minutes late — consistent with the pattern we saw last Friday after the shift extension"
- Audit-trail summaries that compress 200 events into a paragraph a regulator can read
The AI is not a search interface. It surfaces the thing the manager needs to know, when they need to know it, on the screen they already use. The orchestration is more product work than ML work.
Key technical choices:
- Eval set authored before the feature shipped. 180 representative exception scenarios, scored against expected explanations.
- Multi-model routing: cheap model for daily briefs (high volume, structured), capable model for nuanced exception explanations.
- Strict cost guardrails per tenant — generative AI on field workforce data has fast-growing token counts if you're not careful.
What we got wrong
Three things we'd do differently from the start:
-
The mobile sync engine took two attempts. Version one used a custom protocol; it was too clever, hard to debug, and produced occasional sync inversions under adversarial network conditions. Version two used CRDTs for the attendance event log and a simpler last-write-wins for user-edited fields. Boring won.
-
We under-invested in admin UI density at first. The MVP admin dashboard was beautiful and minimal. Real operations managers wanted 4× the information per screen — they have 30 sites to monitor, not 3. We rebuilt density in months 6–8.
-
We launched OpsIQ before the eval harness was robust. Early users got useful summaries 85% of the time and weird ones 15%. The fix was infrastructural — better evals, broader coverage — not a model upgrade. We've since reversed that order: no AI feature ships before its eval set holds.
What's next
Onsight is now actively used across multiple on-site operations. The roadmap continues to lean into structured operational truth — every attendance event provable, every exception explainable, every audit defensible. The AI surface keeps getting smarter, but only at the speed the evals say is safe.
If you're building workforce, field operations, or compliance software with similar shape — multi-surface product, intermittent connectivity, regulated outcomes — we'd be glad to compare notes. The lessons above were paid for in real outages and real customer escalations; you don't have to pay for them again.
Read the full Onsight case study or see the live product.
15 years across payments, telco, and platform engineering. Founded Hexcore to prove African engineering can ship at world-class standards.
Why your RAG demo doesn't survive production
A working LLM prototype and an enterprise-grade RAG system are separated by a body of unglamorous infrastructure: evals, guardrails, observability, cost controls, drift detection. Here's the checklist we use to close the gap.
The four practices that turn a launch into a durable product
Most launches succeed. Most products fail soon after. The gap is not engineering talent — it's a set of operating practices that the strongest teams treat as defaults. Here are the four we install on every Hexcore engagement.
Boring on purpose: why Go quietly won the modern backend
Go was never the fashionable choice. It was always the durable one. Here's why we reach for Go first when we're building backend services that have to last — and the specific patterns we use to keep them clean as the codebase grows.