Slack Room: #migrate
Implementation issues:
Main Flow Phase 1: Add Odometer expense type
Bugs/Improvements:
- Phase 1 blockers
- Phase 1 non-blockers
Main Flow Release 2: Add 'Save for later' feature
Bugs/Improvements:
- Phase 2 blockers
- Phase 2 non-blockers
Related:
Proposal
Add Odometer mileage expenses to NewDot
Background
Expensify is completing the migration from Classic to NewDot. Feature parity is essential for retaining users during this migration, and odometer tracking is one of the few remaining blockers to achieving this. Manual odometer tracking is necessary for users who prefer explicit control over mileage entries rather than automatic GPS tracking, particularly for those who drive frequently for work and need precise records for tax purposes and reimbursement.
Problem
When users track distance expenses via odometer readings in Classic, if they are migrated to NewDot, then they must either manually calculate total distance (losing odometer proof and audit trail) or abandon NewDot to stay in classic or switch to a competing application.
Solution
Introduce odometer mileage as a distance tracking method in NewDot with feature parity to Classic. Users will be able to:
- Select the new Odometer tab in the Track Distance page
- Manually enter start and end mileage readings
- Attach photos of each reading
- View calculated odometer readings and submit as a distance expense
For compatibility and parity, the feature will use the same NVP storage approach (odometerStart, odometerEnd) and validation logic (preventing negative distances, requiring both readings for submission) as Classic.
Tasks
DESIGN DOC ➡️
Slack Room: #migrate
Implementation issues:
Main Flow Phase 1: Add Odometer expense type
Bugs/Improvements:
isOdometerDistanceRequesttransactionMain Flow Release 2: Add 'Save for later' feature
Bugs/Improvements:
Related:
Proposal
Add Odometer mileage expenses to NewDot
Background
Expensify is completing the migration from Classic to NewDot. Feature parity is essential for retaining users during this migration, and odometer tracking is one of the few remaining blockers to achieving this. Manual odometer tracking is necessary for users who prefer explicit control over mileage entries rather than automatic GPS tracking, particularly for those who drive frequently for work and need precise records for tax purposes and reimbursement.
Problem
When users track distance expenses via odometer readings in Classic, if they are migrated to NewDot, then they must either manually calculate total distance (losing odometer proof and audit trail) or abandon NewDot to stay in classic or switch to a competing application.
Solution
Introduce odometer mileage as a distance tracking method in NewDot with feature parity to Classic. Users will be able to:
For compatibility and parity, the feature will use the same NVP storage approach (odometerStart, odometerEnd) and validation logic (preventing negative distances, requiring both readings for submission) as Classic.
Tasks
#whatsnextstrategy@expensify.comand paste in the Proposalstrategy@expensify.com(continue the same email chain as before - your last message should be the WN Proposal) with the link to your Design Doc containing your high-level problem and solutionDesignDocReviewlabel to get the High-level overview of the problem and High-level of proposed solution section reviewedDesignDocReviewlabel to this issuestrategy@expensify.comone last time to let them know the Design Doc is moving into the implementation phasestrategy@expensify.comonce everything has been implemented and do a Project Wrap-Up retrospective that provides: