CaseWorthy (formerly Eccovia) · 2023–2025
Connecting a case management platform with last-mile delivery software to help health and human services organizations deliver meals to vulnerable people — spanning three vendor evaluations, five user personas, and a build-vs-buy journey that transformed reactive one-off integrations into a scalable platform capability.
One of the less obvious but critical challenges was enabling safe development, testing, and debugging without impacting live delivery operations.
Unforeseen challenge: I underestimated how much time and attention environment management would require. In hindsight, I'd design the multi-environment architecture upfront rather than retrofitting it after realizing we needed safe iteration paths that wouldn't disrupt active meal delivery operations.
| Program | Enrolled | Status | Frequency |
|---|---|---|---|
| Home-Delivered Meals — Medical | 01/15/2024 | Active | 3x/week |
| Wellness Check-in Calls | 01/15/2024 | Active | Weekly |
| Date | Meals | Driver | Status | Notes |
|---|---|---|---|---|
| 04/23 | 2 | M. Torres (Staff) | Delivered | Left with front desk |
| 04/21 | 2 | M. Torres (Staff) | Delivered | Handed to client |
| 04/18 | 2 | B. Chen (Vol.) | Missed | Client not home |
| 04/16 | 2 | M. Torres (Staff) | Delivered | — |
| Meal Type | Count |
|---|---|
| Regular | 12 |
| Diabetic | 8 |
| Low Sodium | 6 |
| Pureed | 3 |
| Renal | 4 |
| Gluten-free | 2 |
| Total | 35 |
| Client | Address | Diet | Meals | Driver | Status | |
|---|---|---|---|---|---|---|
| Margaret H. | 2841 S Highland Dr | Diabetic, Low-Na | 2 | Staff | Delivered | |
| Robert P. | 1190 E 3300 S | Regular | 1 | Staff | Delivered | |
| Dorothy M. | 4560 S 900 E, #12 | Pureed, GF | 3 | Volunteer | Manual Entry | |
| James W. | 6789 Cottonwood St | Renal | 2 | Staff | In Transit | |
| Helen K. | 3321 Murray Blvd | Diabetic | 1 | Volunteer | Missed | |
| Frank L. | 7200 Bengal Blvd | Low-Na, Soft | 2 | Staff | Ready |
New volunteers could start delivering within minutes of receiving a text invite. Drivers marked deliveries as complete or missed (with a reason), and those events fired webhooks back to ClientTrack automatically.

Optimized route with turn-by-turn nav. Delivery details, special instructions, and communication with dispatcher/recipient.

Near-zero onboarding friction. This was the key differentiator vs. WorkWave — volunteers actually adopted it.

Drivers could contact recipients directly — reducing missed deliveries when a client wasn't answering the door.

After sending the batch from ClientTrack, planners used Onfleet's web dashboard to optimize driver assignments, sequence deliveries, and monitor routes in real-time.
Program staff reported on delivery outcomes for program impact, funder requirements, and identifying clients with recurring misses.
| Client | Missed | Total | Rate | Common Reason |
|---|---|---|---|---|
| Helen K. | 5 | 12 | 58% | Client not home |
| Arthur G. | 3 | 13 | 77% | Wrong address |
All mockups are representative. The actual ClientTrack UI used the platform's configurable form designer with API plug-ins.
Onfleet's app dramatically improved driver adoption vs. WorkWave — but some elderly volunteers still preferred paper. We needed a dual-path approach.
Build vs. Buy: Route optimization, driver apps, and real-time GPS are hard, specialized problems. Our value was connecting case management context — who needs what, with what dietary restrictions, and did they receive it — to the delivery operation. Onfleet's API and UX quality validated this decision repeatedly.
The WorkWave lesson: A tool can be excellent for dispatchers but fail if drivers won't use it. The best route optimization in the world doesn't matter if the driver is on paper and no one knows whether the meal was delivered until they return. Onfleet succeeded because it treated the driver as a first-class user, not an afterthought.
Instead of building what customers suggested and discovering better options later, I'd invest in a structured vendor evaluation early — scoring on API quality, webhook support, driver UX, onboarding friction, and pricing. The path from Samsara to WorkWave to Onfleet was educational but not efficient.
The volunteer driver gap was foreseeable given the population. I'd invest earlier in the manual fallback UX and think harder about whether paper and digital could coexist more gracefully.
The two WorkWave customers getting different solutions from separate teams created inconsistency. Establishing shared patterns and documentation earlier would have prevented this divergence and made the Onfleet transition smoother.
The dev/sandbox vs. production environment setup for API key management and webhook routing took more time and attention than anticipated. I'd design that architecture upfront rather than retrofitting it after realizing we needed safe iteration and debugging paths that wouldn't disrupt active delivery operations.