Why we're building kitwheel

Every facilities platform wants to be your system of record. None of them wants to talk to the others. So the actual integration layer of this industry is a person with two monitors, retyping work orders from one portal into another.

We've spent months reading work-order APIs: the big platforms, endpoint by endpoint. The surprising part isn't that integration is hard. It's where it's hard. The HTTP part is easy. The hard part is that the same work order doesn't mean the same thing twice.

Here's one real example of the problem. The same job, as two different platforms see it:

{
  "workorder": {
    "id": 48213,
    "status": "IN_PROGRESS",
    "priority_id": 7,
    "trade": "HVAC",
    "nte": 1500.00
  }
}

{
  "job": {
    "id": "J-2201",
    "jobStatus": "Dispatched",
    "priority": "Urgent",
    "jobTypeId": 118,
    "appointments": [{"start": "2026-08-05T13:00:00Z"}]
  }
}

Same physical technician, same broken rooftop unit. One system says IN_PROGRESS against a tenant-configured priority table; the other says Dispatched and won't even let the job exist without an appointment. Neither is wrong. They just speak different dialects. Today, a human translates.

kitwheel is the hub in the middle: it speaks each platform's dialect, translates statuses and vocabularies both ways, and keeps every connected system telling the same story about the same work order.

We're onboarding a small group of early teams. If your week includes retyping work orders, join the beta.