ServiceLens / DiagBuddyGO

Field-service technicians across six equipment verticals — appliance, HVAC, electrical, phone and tablet, IT hardware, and dental equipment — working from a phone in somebody's kitchen or plant room. The product began as an earlier build whose front end had fragmented into three competing surfaces, and was rebuilt around one navigation.

A technician on site has minutes, not an afternoon. General-purpose AI answers a repair question confidently and wrongly because it has never seen this model. The office side was worse: dispatch, the diagnosis, the part and the stock count lived in different places, so the same job was entered three times.

• A diagnostic path sized to the job: a quick prescreen, a full diagnosis, a photo scan, and a chat mode, each with a per-vertical persona rather than one assistant pretending to know every trade.
• Answers grounded in the technician's own past diagnoses through retrieval, so the system reasons from work this company actually did.
• Dispatch to diagnosis to parts to inventory as one continuous workflow, with customer CRM, customer profiles, service dispatch, inventory and team management all scoped to the company.
• Reference tools that stop the guessing: parts and model lookup, and an error-code library covering the six verticals including dental equipment.
• Role and tier gating — administrator, manager, technician — with company scoping enforced in the data layer rather than the interface.
• A mobile-first installable app with fifteen languages, and PDF diagnostic reports the office can file.
• Outbound push to the CRM a company already runs, so the platform does not demand that they leave it.

• Webhook push to Housecall Pro, Jobber, ServiceTitan and Zapier.
• Stripe subscriptions, with company billing activation and revocation verified live: an active company gets through, an inactive one is refused at the payment-required boundary.
• PostgreSQL with an additive-only schema rule, so a migration cannot destroy a column somebody's data is in.

• Authentication, the diagnostic engine, the dispatch-to-diagnose-to-prescreen-to-parts-to-inventory walk, and team billing activation and revocation were each verified against the live deployment with real accounts, not a staging fixture.
• Per-user isolation and ownership checks confirmed with no cross-company leaks found.
• The office backends — CRM, dispatch, inventory, jobs — were audited for company scoping on every query.
• A failed build leaves the previous container running, so a bad deploy does not take the product down.

No revenue, saving or headcount figure appears on this page. Where a client has not approved a number for publication, we leave it out rather than estimate one.

• Diagnostic accuracy is not published as a percentage. There is no benchmark we would defend, and a number without a test set behind it would be marketing.
• Webhook idempotency is held in memory rather than in a table, so a duplicate delivery across a restart is possible. It is a known item, not a discovered one.
• Self-serve checkout for the company and enterprise tiers is wired on the backend and the signup-to-checkout flow is the last mile.

SOPHIA XT

Product, platform and application engineering; the diagnostic corpus; deployment and operations.

3 Point Forward

No consulting engagement on this one — it was delivered by the engineering arm directly for the client.

Want one of these?

If you already know what needs building, talk to us directly. If the operational problem is not pinned down yet — which is more often the case — start with the business systems assessment on the consulting side and come back with a plan.