# Best Practices

Every integration is a little different, but a few patterns tend to separate a smooth rollout from a bumpy one. These are drawn from real pilots and deep integrations: pick the section that matches where you are, and treat the rest as worth a skim before you get there.

## Piloting a new integration

- **Start small.** A small, closely-monitored cohort, a handful of tours or drivers, catches issues faster than a depot-wide rollout, and is easier to walk back if something's off.
- **Pilot where geocoding is reliable.** Address accuracy is usually the biggest blocker to a smooth pilot. Starting somewhere geocoding is strong avoids a lot of avoidable noise.
- **Consider shadowing first.** For a tenant not quite ready to go live, running Better Route in the background, collecting and validating data without driver interaction, is a low-risk way to verify data quality before a live pilot.
- **Agree on ID and format conventions in writing before go-live.** Details like tour-number-vs-login-ID or postal code granularity are easy to leave implicit. Mismatches here have caused real outages, not just friction, so nail these down explicitly upfront.
- **Plan for what happens after the initial pilot segment.** Rollouts often stall right at the boundary of the pilot group, for example extending from an initial depot to the wider fleet. Plan that path from the start rather than treating it as a later problem.


## Driver App

- **Don't make drivers switch apps manually.** On a shared device, add the [App-to-App Library](/products/route/resources/app-to-app-library) so the two apps hand off directly. It's only a few hours of work to implement but saves a lot of time for drivers.


## Deep Integration

- **Treat `FIXED_OPTIMIZATION` as your steady state.** Reach for `FULL_OPTIMIZATION` only when [checking for recalculation gain](/products/route/resources/deep-integration-index#checking-for-recalculation-gain) shows it's worth it, then switch back, repeated full re-optimisation costs the driver a familiar order for little gain.
- **Let drivers set timing the system can't estimate.** For security checks, congested docks, or off-connector jobs like a charging stop, a [custom stop time](/products/route/resources/deep-integration-index#setting-custom-stop-times) keeps the sequence accurate instead of guessing. The same logic applies to [custom jobs](/products/route/resources/deep-integration-index#custom-jobs): pair one with a custom timeframe and stop time so it's reflected accurately rather than sitting as a rough guess in the sequence.
- **Be clear on what you're optimising for before committing.** Deep integration buys full control, but it's a materially heavier commitment than the Driver App: weeks or months of build, plus ongoing maintenance as the Better Route API evolves. Make sure the tradeoff is worth it.
- **Get a dedicated test tenant**, so QA and connector testing never touch production.
- **Audit shortcuts before going live.** Simplified or hardcoded behaviour, cached values, for example, can look fine in a sandbox but distort real metrics once live. Review before you cut over.


## Known limitations

- The [Navigation SDK](/products/route/sdks/navigation-sdk) is still early-stage and will need to be tested in operations.
- Personal-Device mode doesn't have full feature parity with a Managed Device setup (iOS is furthest behind), and the shared-device setup (Driver App alongside your scanner or loading app) isn't available on Personal-Device either.