764 lines
18 KiB
Markdown
764 lines
18 KiB
Markdown
# MotorSignal Product Roadmap
|
|
|
|
**Status:** Planning baseline
|
|
**Date:** 2026-09-01
|
|
**Product:** MotorSignal motorcycle telemetry, ride analysis, cloud, and riding platform
|
|
|
|
## Vision
|
|
|
|
MotorSignal should evolve from a motorcycle telemetry app into a reliable riding platform:
|
|
|
|
> Create account → Add motorcycle → Ride → Analyze → Automatically sync → Build riding history → Connect with friends → Plan rides → Ride together.
|
|
|
|
The application should remain **offline-first**. Cloud and social features should extend the core riding experience rather than make basic recording dependent on an internet connection.
|
|
|
|
## Roadmap Principles
|
|
|
|
1. Stabilize existing functionality before adding major new features.
|
|
2. Design cloud storage and identity early so later social features do not require a backend redesign.
|
|
3. Keep Free genuinely useful.
|
|
4. Make Pro valuable through advanced capabilities, cloud convenience, and deeper analysis.
|
|
5. Treat Google Play purchase state as the authority for paid entitlement.
|
|
6. Keep user location and ride data private by default.
|
|
7. Never expose sensitive home/start/end locations unnecessarily.
|
|
8. Build offline-first synchronization with clear conflict handling.
|
|
9. Prefer incremental, testable phases over a large rewrite.
|
|
|
|
---
|
|
|
|
## Phase 0 — Current Build Stabilization
|
|
|
|
**Goal:** Make the existing MotorSignal experience reliable before monetization.
|
|
|
|
### Garage
|
|
|
|
- [x] Real motorcycle image on main Garage page.
|
|
- [x] Real motorcycle image during motorcycle creation.
|
|
- [ ] Replace old render on Technical Details page.
|
|
- [ ] Replace old render in Evolution detail view.
|
|
- [ ] Audit every other motorcycle-image location.
|
|
- [ ] Ensure selected year/make/model remains consistent throughout the UI.
|
|
- [ ] Verify editing a motorcycle preserves its identity/image.
|
|
|
|
### Ride Pipeline
|
|
|
|
- [ ] Verify ride recording.
|
|
- [ ] Verify ride persistence.
|
|
- [ ] Verify ride history.
|
|
- [ ] Verify route preview.
|
|
- [ ] Fix/verify acceleration layer.
|
|
- [ ] Fix/verify braking layer.
|
|
- [ ] Verify lean layer.
|
|
- [ ] Verify ride summary.
|
|
- [ ] Verify CSV/PDF exports.
|
|
- [ ] Verify ride processing after app restart.
|
|
|
|
### Authentication / Existing Cloud Behavior
|
|
|
|
- [ ] Google login → History → select ride → Upload Now.
|
|
- [ ] Settings → Back up all.
|
|
- [ ] Verify authentication state consistency.
|
|
- [ ] Verify logout/login behavior.
|
|
- [ ] Verify offline operation and later synchronization.
|
|
|
|
### Reliability Tests
|
|
|
|
- [ ] Screen off.
|
|
- [ ] App backgrounded.
|
|
- [ ] Phone locked.
|
|
- [ ] Incoming call/interruption.
|
|
- [ ] Bluetooth disconnect/reconnect.
|
|
- [ ] GPS loss/recovery.
|
|
- [ ] OBD disconnect/reconnect.
|
|
- [ ] Low battery.
|
|
- [ ] Low storage.
|
|
- [ ] App restart.
|
|
|
|
### Exit Criteria
|
|
|
|
A user can:
|
|
|
|
> Add motorcycle → record ride → stop → view ride → analyze ride → close app → reopen → ride remains available.
|
|
|
|
---
|
|
|
|
## Phase 1 — Account & User Identity
|
|
|
|
**Goal:** Establish the user identity that all cloud and social features can build upon.
|
|
|
|
### Account
|
|
|
|
- [ ] User profile model.
|
|
- [ ] Stable internal user ID.
|
|
- [ ] Google authentication.
|
|
- [ ] Persistent sessions.
|
|
- [ ] Sign out.
|
|
- [ ] Account deletion.
|
|
- [ ] Re-authentication where required.
|
|
- [ ] Data export.
|
|
|
|
### Profile
|
|
|
|
- [ ] Profile photo.
|
|
- [ ] Display name.
|
|
- [ ] Unique username.
|
|
- [ ] Bio.
|
|
- [ ] Optional location.
|
|
- [ ] Riding statistics.
|
|
- [ ] Public/private profile setting.
|
|
|
|
### Privacy
|
|
|
|
Add independent visibility controls for:
|
|
|
|
- Profile.
|
|
- Garage.
|
|
- Ride history.
|
|
- Statistics.
|
|
- Location.
|
|
- Friend requests.
|
|
|
|
Do not use the public username as the underlying account identity.
|
|
|
|
---
|
|
|
|
## Phase 2 — Cloud Data Architecture
|
|
|
|
**Goal:** Establish a scalable, secure cloud model without abandoning local storage.
|
|
|
|
### Architecture
|
|
|
|
```text
|
|
MotorSignal
|
|
│
|
|
┌──────────┴──────────┐
|
|
│ │
|
|
Local Database Cloud
|
|
(offline) (Firebase)
|
|
│ │
|
|
└──────────┬──────────┘
|
|
│
|
|
Sync Engine
|
|
```
|
|
|
|
### Primary Cloud Objects
|
|
|
|
```text
|
|
users/{userId}
|
|
users/{userId}/motorcycles/{motorcycleId}
|
|
users/{userId}/rides/{rideId}
|
|
users/{userId}/trips/{tripId}
|
|
users/{userId}/events/{eventId}
|
|
users/{userId}/friends/{friendId}
|
|
```
|
|
|
|
Group rides can later use a dedicated top-level collection if required by query/security requirements.
|
|
|
|
### Common Object Metadata
|
|
|
|
Every synchronizable object should have a consistent strategy for:
|
|
|
|
- Stable ID.
|
|
- Owner ID.
|
|
- Created timestamp.
|
|
- Updated timestamp.
|
|
- Soft-delete timestamp where appropriate.
|
|
- Sync state.
|
|
- Version/conflict metadata where necessary.
|
|
|
|
---
|
|
|
|
## Phase 3 — Offline-First Sync Engine
|
|
|
|
**Goal:** Make cloud synchronization reliable instead of treating backup as a manual upload.
|
|
|
|
### Sync States
|
|
|
|
- `LOCAL_ONLY`
|
|
- `PENDING_UPLOAD`
|
|
- `SYNCED`
|
|
- `PENDING_DELETE`
|
|
- `CONFLICT`
|
|
|
|
### Required Behavior
|
|
|
|
- Record rides without internet.
|
|
- Queue cloud operations locally.
|
|
- Automatically synchronize when connectivity returns.
|
|
- Retry failed operations safely.
|
|
- Avoid duplicate rides/uploads.
|
|
- Handle partial synchronization.
|
|
- Detect conflicts.
|
|
- Never silently delete local user data.
|
|
- Show synchronization status to the user.
|
|
|
|
### User Experience
|
|
|
|
Provide a clear cloud status such as:
|
|
|
|
> ☁️ Everything is synced
|
|
|
|
or:
|
|
|
|
> ☁️ 3 rides waiting to sync
|
|
|
|
---
|
|
|
|
## Phase 4 — Cloud Backup & Restore
|
|
|
|
**Goal:** Make a user's MotorSignal history portable across devices.
|
|
|
|
### Pro Cloud Features
|
|
|
|
- Unlimited ride backup.
|
|
- Automatic synchronization.
|
|
- Motorcycle synchronization.
|
|
- Routes.
|
|
- Ride statistics.
|
|
- Reports.
|
|
- Settings/preferences where appropriate.
|
|
- Multi-device restore.
|
|
|
|
### Settings
|
|
|
|
Add a dedicated Cloud Sync area containing:
|
|
|
|
- Account identity.
|
|
- Sync status.
|
|
- Last successful sync.
|
|
- Sync Now.
|
|
- Automatic Sync toggle.
|
|
- Optional Wi-Fi-only setting.
|
|
- Restore Data.
|
|
- Export My Data.
|
|
|
|
---
|
|
|
|
## Phase 5 — Monetization Architecture
|
|
|
|
**Goal:** Create a durable entitlement system before placing feature gates throughout the application.
|
|
|
|
### Entitlements
|
|
|
|
Use centralized product/entitlement states:
|
|
|
|
- `FREE`
|
|
- `PRO_MONTHLY`
|
|
- `PRO_LIFETIME`
|
|
|
|
The entitlement layer should expose feature capabilities rather than encourage scattered `isPremium` checks.
|
|
|
|
Examples:
|
|
|
|
- `canCloudBackup`
|
|
- `canAdvancedTelemetry`
|
|
- `canExport`
|
|
- `canTripPlanning`
|
|
- `canGroupRides`
|
|
- `canAdvancedAnalytics`
|
|
- `canUseMultipleMotorcycles`
|
|
|
|
### Rules
|
|
|
|
- Google Play purchase state is authoritative for Play purchases.
|
|
- Firebase account identity must not be the sole source of Pro entitlement.
|
|
- Local entitlement state may be cached for usability, but must reconcile with authoritative billing state.
|
|
- Restore must work after reinstall and on another device.
|
|
|
|
---
|
|
|
|
## Phase 6 — Google Play Products
|
|
|
|
**Goal:** Ship stable Free, Monthly, and Lifetime offerings.
|
|
|
|
### Products
|
|
|
|
- MotorSignal Pro Monthly — subscription.
|
|
- MotorSignal Pro Lifetime — non-consumable one-time purchase.
|
|
|
|
Do not hard-code prices in the application. Read current product information from Google Play.
|
|
|
|
### Required Billing Tests
|
|
|
|
- Fresh install.
|
|
- Free user.
|
|
- Monthly purchase.
|
|
- Restore purchase.
|
|
- Renewal.
|
|
- Cancellation.
|
|
- Grace period.
|
|
- Account hold.
|
|
- Expiration.
|
|
- Reinstall.
|
|
- Second device.
|
|
- Lifetime purchase.
|
|
- Lifetime restore.
|
|
- Already-owned product.
|
|
- Purchase cancellation.
|
|
- Billing/network failure.
|
|
- Play Store unavailable.
|
|
- Product unavailable.
|
|
|
|
---
|
|
|
|
## Phase 7 — Paywall & Pro UX
|
|
|
|
**Goal:** Clearly communicate the value of Pro without crippling Free.
|
|
|
|
### Paywall
|
|
|
|
Present:
|
|
|
|
- Cloud backup.
|
|
- Advanced analytics.
|
|
- Advanced route layers.
|
|
- Unlimited ride history.
|
|
- Multiple motorcycles.
|
|
- Trip planning.
|
|
- Group rides.
|
|
- Advanced statistics.
|
|
- Future premium features.
|
|
|
|
Include:
|
|
|
|
- Monthly option.
|
|
- Lifetime option.
|
|
- Restore Purchases.
|
|
- Terms/privacy access where appropriate.
|
|
|
|
### In-App Upgrade UX
|
|
|
|
Use consistent PRO labels/locks and route users to the paywall when they attempt a premium feature.
|
|
|
|
### Settings
|
|
|
|
Show:
|
|
|
|
- Current plan.
|
|
- Renewal/expiration information where applicable.
|
|
- Restore Purchases.
|
|
- Manage Subscription.
|
|
|
|
---
|
|
|
|
## Phase 8 — Friends & Social Identity
|
|
|
|
**Goal:** Add a controlled rider network without immediately becoming a general-purpose social network.
|
|
|
|
### Username
|
|
|
|
- Unique.
|
|
- Case-insensitive.
|
|
- Searchable.
|
|
- Changeable with reasonable restrictions.
|
|
- Reserved-word protection.
|
|
|
|
### Friends
|
|
|
|
- Find riders.
|
|
- Friend requests.
|
|
- Accept/decline.
|
|
- Friends list.
|
|
- Remove friend.
|
|
- Block user.
|
|
- Report user.
|
|
|
|
Keep profile/friend functionality available to Free users to encourage network growth.
|
|
|
|
---
|
|
|
|
## Phase 9 — Motorcycle Profiles
|
|
|
|
**Goal:** Make motorcycles part of the rider's identity.
|
|
|
|
For each motorcycle, support optional public presentation of:
|
|
|
|
- Year/make/model.
|
|
- Motorcycle photo.
|
|
- Nickname.
|
|
- Mileage.
|
|
- Ride count.
|
|
- Modifications.
|
|
- Statistics.
|
|
|
|
Visibility should follow the user's privacy settings.
|
|
|
|
---
|
|
|
|
## Phase 10 — Planned Rides
|
|
|
|
**Goal:** Let users organize future rides.
|
|
|
|
### Planned Ride Model
|
|
|
|
Support:
|
|
|
|
- Name.
|
|
- Date.
|
|
- Meeting time.
|
|
- Departure time.
|
|
- Meeting location.
|
|
- Destination.
|
|
- Route.
|
|
- Description.
|
|
- Waypoints.
|
|
- Fuel stops.
|
|
- Food/rest stops.
|
|
- Scenic stops.
|
|
- Motorcycle-related stops.
|
|
|
|
A planned ride can remain private or be shared with friends/group members.
|
|
|
|
---
|
|
|
|
## Phase 11 — Events & Meetups
|
|
|
|
**Goal:** Separate casual motorcycle gatherings from actual rides.
|
|
|
|
Example:
|
|
|
|
> Sunday Coffee & Motorcycles — 9:00 AM
|
|
|
|
Support:
|
|
|
|
- Event creation.
|
|
- Location.
|
|
- Date/time.
|
|
- Description.
|
|
- Attendee list.
|
|
- Join/maybe/can't attend.
|
|
- Organizer controls.
|
|
- Optional conversion from meetup to group ride.
|
|
|
|
---
|
|
|
|
## Phase 12 — Group Rides
|
|
|
|
**Goal:** Make coordinated motorcycle riding a signature MotorSignal feature.
|
|
|
|
### Group Ride
|
|
|
|
- Organizer.
|
|
- Rider list.
|
|
- Route.
|
|
- Meeting point.
|
|
- Departure time.
|
|
- Route progress.
|
|
- Group ride status.
|
|
- Ride completion.
|
|
- Individual ride telemetry.
|
|
|
|
Each rider should retain their own ride record while the group ride creates a shared event context.
|
|
|
|
Conceptually:
|
|
|
|
```text
|
|
User → Motorcycle → Ride → Group Ride
|
|
```
|
|
|
|
A solo ride does not require a Group Ride relationship.
|
|
|
|
---
|
|
|
|
## Phase 13 — Group Ride Location & Safety
|
|
|
|
**Goal:** Add live group awareness while protecting rider privacy.
|
|
|
|
### Location Sharing
|
|
|
|
- Off by default outside active group rides.
|
|
- Explicit consent before sharing during a group ride.
|
|
- Automatically stop sharing when the group ride ends.
|
|
- Show last-known position when appropriate rather than claiming continuous tracking.
|
|
- Avoid exposing home/start/end locations unnecessarily.
|
|
|
|
Potential future capabilities:
|
|
|
|
- Rider separated from group.
|
|
- Rider stopped unexpectedly.
|
|
- Group split detection.
|
|
- Last-known location.
|
|
- Emergency assistance.
|
|
|
|
Safety features must never encourage riders to interact with the screen while moving.
|
|
|
|
---
|
|
|
|
## Phase 14 — Multi-Day Trip Planning
|
|
|
|
**Goal:** Support complete motorcycle trips rather than individual rides.
|
|
|
|
### Trip
|
|
|
|
- Trip name.
|
|
- Start/end dates.
|
|
- Multiple days.
|
|
- Daily routes.
|
|
- Waypoints.
|
|
- Fuel stops.
|
|
- Rest stops.
|
|
- Food.
|
|
- Hotels.
|
|
- Scenic locations.
|
|
- Notes.
|
|
|
|
Example:
|
|
|
|
```text
|
|
Tail of the Dragon Weekend
|
|
|
|
Day 1: Atlanta → Cherokee
|
|
Day 2: Cherokee → Deals Gap → Gatlinburg
|
|
Day 3: Gatlinburg → Atlanta
|
|
```
|
|
|
|
---
|
|
|
|
## Phase 15 — Collaborative Trips
|
|
|
|
**Goal:** Allow invited riders to participate in trip planning.
|
|
|
|
Support:
|
|
|
|
- Trip organizer.
|
|
- Invited riders.
|
|
- Shared routes.
|
|
- Shared stops.
|
|
- Shared notes.
|
|
- Trip-specific events.
|
|
- Group ride association.
|
|
- Trip history after completion.
|
|
|
|
---
|
|
|
|
## Phase 16 — Ride Sharing
|
|
|
|
**Goal:** Turn completed rides into shareable summaries while protecting raw data.
|
|
|
|
A shared ride summary can include:
|
|
|
|
- Distance.
|
|
- Duration.
|
|
- Top speed.
|
|
- Maximum lean.
|
|
- Acceleration records.
|
|
- Personal bests.
|
|
- Route preview.
|
|
- Motorcycle.
|
|
- Photos where permitted.
|
|
|
|
Visibility choices:
|
|
|
|
- Private.
|
|
- Friends.
|
|
- Public.
|
|
|
|
Raw GPS telemetry should not automatically become public merely because a ride is shared.
|
|
|
|
---
|
|
|
|
## Phase 17 — Achievements & Riding History
|
|
|
|
**Goal:** Make the accumulated ride history meaningful.
|
|
|
|
Potential achievements:
|
|
|
|
- First Ride.
|
|
- 1,000 Miles.
|
|
- 100 Rides.
|
|
- 10,000 Miles.
|
|
- Night Rider.
|
|
- Mountain Rider.
|
|
- First Group Ride.
|
|
- First Trip.
|
|
- Personal Best.
|
|
|
|
Achievements should be derived from recorded/verified ride data rather than freely editable user values.
|
|
|
|
---
|
|
|
|
## Phase 18 — Future Social/Discovery Layer
|
|
|
|
**Goal:** Expand only after the core platform is proven.
|
|
|
|
Potential future features:
|
|
|
|
- Activity feed.
|
|
- Comments.
|
|
- Likes.
|
|
- Public routes.
|
|
- Local riding groups.
|
|
- Clubs.
|
|
- Public meetups.
|
|
- Route discovery.
|
|
- Ride recommendations.
|
|
- Messaging.
|
|
|
|
These are explicitly **not launch blockers** for the first Pro release.
|
|
|
|
---
|
|
|
|
# Proposed Navigation Evolution
|
|
|
|
Eventually the primary navigation can evolve toward:
|
|
|
|
```text
|
|
HOME
|
|
GARAGE
|
|
RIDES
|
|
EXPLORE
|
|
PROFILE
|
|
```
|
|
|
|
### Home
|
|
|
|
Current motorcycle, ride status, quick start, important alerts.
|
|
|
|
### Garage
|
|
|
|
Motorcycles and motorcycle details.
|
|
|
|
### Rides
|
|
|
|
Ride history, planned rides, trips, and group rides.
|
|
|
|
### Explore
|
|
|
|
Friends, events, public rides, public routes, and later local discovery.
|
|
|
|
### Profile
|
|
|
|
Identity, statistics, achievements, motorcycles, and privacy.
|
|
|
|
---
|
|
|
|
# Initial Free / Pro / Lifetime Direction
|
|
|
|
| Feature | Free | Pro Monthly | Pro Lifetime |
|
|
|---|:---:|:---:|:---:|
|
|
| Motorcycle Garage | ✓ | ✓ | ✓ |
|
|
| Basic Ride Recording | ✓ | ✓ | ✓ |
|
|
| Basic Ride History | ✓ | ✓ | ✓ |
|
|
| Basic Telemetry | ✓ | ✓ | ✓ |
|
|
| Basic Route View | ✓ | ✓ | ✓ |
|
|
| User Account | ✓ | ✓ | ✓ |
|
|
| Profile | ✓ | ✓ | ✓ |
|
|
| Friends | ✓ | ✓ | ✓ |
|
|
| Limited Cloud Backup | ✓ | — | — |
|
|
| Unlimited Cloud Backup | — | ✓ | ✓ |
|
|
| Advanced Analytics | — | ✓ | ✓ |
|
|
| Advanced Route Layers | — | ✓ | ✓ |
|
|
| Unlimited Ride History | — | ✓ | ✓ |
|
|
| PDF/CSV Export | — | ✓ | ✓ |
|
|
| Multiple Motorcycles | Limited | ✓ | ✓ |
|
|
| Trip Planning | — | ✓ | ✓ |
|
|
| Group Rides | — | ✓ | ✓ |
|
|
| Advanced Statistics | — | ✓ | ✓ |
|
|
| Future Premium Features | — | ✓ | ✓ |
|
|
|
|
**This matrix is a planning baseline, not the final commercial contract.** Every row should be reconciled against the actual implemented feature set before Play Store launch.
|
|
|
|
---
|
|
|
|
# Release Gates
|
|
|
|
## Gate 1 — Technical Readiness
|
|
|
|
- Existing ride pipeline stable.
|
|
- Critical bugs resolved.
|
|
- Release build succeeds.
|
|
- No known data-loss bugs.
|
|
|
|
## Gate 2 — Cloud Readiness
|
|
|
|
- Firebase security rules audited.
|
|
- User ownership enforced.
|
|
- Offline sync tested.
|
|
- Backup/restore tested.
|
|
- Account deletion tested.
|
|
- Data export tested.
|
|
|
|
## Gate 3 — Monetization Readiness
|
|
|
|
- Monthly product configured.
|
|
- Lifetime product configured.
|
|
- Entitlements centralized.
|
|
- Restore tested.
|
|
- Subscription lifecycle tested.
|
|
- Paywall complete.
|
|
|
|
## Gate 4 — Beta Readiness
|
|
|
|
- Internal testing complete.
|
|
- Closed testing complete.
|
|
- Crash/error monitoring reviewed.
|
|
- Real-device motorcycle testing complete.
|
|
- Privacy/Terms/Data Safety requirements completed.
|
|
|
|
## Gate 5 — Production
|
|
|
|
- Store listing finalized.
|
|
- Release signing verified.
|
|
- Production billing products verified.
|
|
- Production Firebase configuration verified.
|
|
- Backup/restore verified on production build.
|
|
|
|
---
|
|
|
|
# Immediate Development Priority
|
|
|
|
The recommended order from the current state is:
|
|
|
|
1. Finish Technical Details motorcycle image consistency.
|
|
2. Audit all existing motorcycle/ride UI for stale rendering paths.
|
|
3. Finish and verify acceleration/braking/lean analysis.
|
|
4. Verify the complete ride lifecycle.
|
|
5. Resolve the History → Upload Now authentication issue.
|
|
6. Audit Firebase security and cloud ownership.
|
|
7. Define the final cloud data model.
|
|
8. Implement the offline-first sync layer.
|
|
9. Implement profile/account architecture.
|
|
10. Implement backup/restore.
|
|
11. Lock the Free/Pro feature matrix.
|
|
12. Implement centralized entitlements.
|
|
13. Configure Monthly and Lifetime products.
|
|
14. Implement paywall and subscription management.
|
|
15. Test billing thoroughly.
|
|
16. Release to internal/closed testing.
|
|
17. Build Friends.
|
|
18. Build Planned Rides.
|
|
19. Build Events/Meetups.
|
|
20. Build Group Rides.
|
|
21. Build multi-day Trips.
|
|
22. Add advanced social/discovery features later.
|
|
|
|
---
|
|
|
|
# Product Definition
|
|
|
|
MotorSignal should not be treated as three unrelated products called Free, Monthly, and Lifetime.
|
|
|
|
There should be **one MotorSignal application and one account/data model**, with different entitlement levels.
|
|
|
|
The long-term architecture should support:
|
|
|
|
```text
|
|
MotorSignal
|
|
│
|
|
┌───────────────┴───────────────┐
|
|
│ │
|
|
Core Riding Rider Network
|
|
│ │
|
|
┌───────┼────────┐ ┌───────┼────────┐
|
|
│ │ │ │ │ │
|
|
Garage Rides Telemetry Friends Events Trips
|
|
│ │ │ │ │ │
|
|
└───────┴────────┴──────────────┴───────┴────────┘
|
|
│
|
|
Cloud + Sync
|
|
│
|
|
Free / Pro Entitlement
|
|
```
|
|
|
|
The immediate objective is **reliability**. The next objective is **cloud identity and synchronization**. Monetization then sits on top of that foundation, followed by the social/group-riding platform.
|