Blocking Now — Must resolve before engineers write the first screen
What constitutes the MVP — full parity or a scoped subset?
Without a clear MVP definition, engineers will scope-creep toward full parity and ship nothing. The current RecTrac MainTrac has years of accumulated features. Many are rarely used. The MVP must be defined before a single screen is designed.
Option A
Full parity before any customer migration. Maximizes safety but likely takes 24+ months and delays all value delivery.
Option B
80% parity — defer contract processing and some edge-case reports. Still a large scope, still delays the first migration significantly.
Option C ★ Recommended
Mobile-only MVP first. Ship the new mobile app (work order management, asset lookup, logging) to existing customers while the web management UI is still being built. Gets value out fast, validates the product with real users, and directly addresses the documented pain points.
Confirm or redirect the mobile-first build sequence
The recommended build sequence ships the mobile app (Phase 3) before the web management UI (Phase 4). This is a deliberate choice based on where the documented customer pain is concentrated — all 8 known gaps are in mobile or adjacent to mobile workflows. Reversing the sequence delays the highest-value work.
Option A ★ Recommended
Mobile first — Phase 3 is the field app, Phase 4 is the web UI. All documented customer pain points are in mobile. The existing web UI, while dated, functions adequately for administrators.
Option B
Web first — rebuild the management UI before shipping mobile. Lower technical risk (web is more familiar to the team) but defers all user-facing value to Phase 4.
Option C
Build both in parallel. Splits team attention, increases coordination cost, and typically results in both being late.
Which 2–3 customers join the beta program?
Beta customers test the mobile app before broad rollout and provide the feedback that shapes the web UI. They need: active MainTrac field staff, technical willingness to tolerate rough edges, and a product contact who will give honest feedback. The wrong beta customers produce either no feedback or noise. Albuquerque is the strongest known candidate based on existing product team engagement and documented pain points.
Option A
Select the smallest, simplest customer. Lowest risk of exposing gaps, but feedback will not represent the broader customer base.
Option B
Let customers self-select by volunteering. Attracts enthusiasts, but may not include the customers with the most at stake.
Option C ★ Recommended
Proactively recruit 2–3 customers who have raised specific pain points (Albuquerque first). Pairs with the Leadership #8 decision to announce the initiative early. These customers become advocates and the feedback is directly actionable.
Needed Soon — Resolve within the first 60 days
Which of the 8 known gaps are in the mobile MVP, and which are deferred?
All 8 documented gaps must be assigned to a phase before engineering begins. The top 3 must be in the mobile MVP or the new app will ship with the same problems customers already have.
| # |
Gap |
Recommended Phase |
Notes |
| 1 |
No staff filtering on mobile work order list |
Mobile MVP |
Top field worker complaint. Must ship in Phase 3. |
| 2 |
Work order email deep links break on mobile |
Mobile MVP |
Broken workflow. Fix in Phase 3 — requires deep link routing setup. |
| 3 |
No logging wizard |
Mobile MVP |
Step-by-step log entry is table stakes for field use. |
| 4 |
No public API (VSXORG-246) |
Phase 5 |
For integrations — does not block core product. |
| 5 |
Thin documentation |
Phase 4–5 |
Ship with web UI. Invest before GA. |
| 6 |
Contract processing (Combination Log hybrid) |
Year 2 |
Only a handful of customers used this. See Decision #5. |
| 7 |
Inspection report WO status blank |
Phase 5 |
Already resolved in RecTrac. Implement correctly in new system. |
| 8 |
Support experience / thin onboarding |
Phase 4–5 |
Improve alongside documentation effort. |
Rebuild contract processing as a first-class feature, or keep the hybrid Combination Log approach?
In RecTrac 10.2, contract processing was a distinct feature. The current RecTrac 3.1 implementation uses a Combination Log hybrid that only a handful of customers relied on. A full rebuild is significant scope; deferring it risks alienating the customers who do use it.
Option A
Full rebuild as a first-class feature. High scope, delays other work, benefits a small subset of customers.
Option B ★ Recommended
Keep the hybrid Combination Log approach for the initial release, add clearer documentation and UX improvements, and schedule a proper rebuild for Year 2 once usage patterns on the new stack are understood.
Option C
Deprecate and replace with a simpler contracts model. Risk: customers using the current hybrid lose functionality without an equivalent replacement.
What is the scope and ship target for the public API (VSXORG-246)?
VSXORG-246 is the planned public API. The documented endpoint scope covers Combination Log, Inspections, and Work Orders. The question is whether this ships alongside the mobile MVP (Phase 3) or in a dedicated later phase. Shipping too early means the API contracts become frozen before the data model stabilizes.
Option A
Ship with mobile MVP (Phase 3). Maximizes early integration opportunities but risks unstable API contracts if the data model is still evolving.
Option B ★ Recommended
Ship in Phase 5, after the core domain model has stabilized through Phase 3 and 4. The API is for integrations, not for the core product — no customer migration is blocked by its absence. Confirm scope: Work Orders, Assets, Combination Log, Inspections.
Option C
Separate product track with its own timeline. Adds coordination overhead; not recommended given team size.
Before Launch — Resolve before any customer goes live
Does the standalone product keep the "MainTrac" name or get a new brand?
The product is being rebuilt from scratch on modern infrastructure. This is an opportunity to rebrand — but rebranding also means abandoning the name recognition that ~80 existing customers already associate with the product. A new brand requires marketing investment; the existing brand carries baggage but also equity.
Option A ★ Recommended
Keep "MainTrac" — the brand is known, customers search for it by name, and the cross-brand play (NextRec/RecDesk) benefits from a recognized maintenance tracking identity. No marketing cost to rename.
Option B
Rename to reflect SaaS/modern positioning (e.g., "Trac" or a new name). Higher marketing cost; risks confusing existing customers during migration.
Option C
Sub-brand: "MainTrac by Vermont Systems." Signals new ownership of the product category while retaining the name. Moderate naming complexity.
In what order do customers migrate from RecTrac MainTrac to the new stack?
~80 customers need to migrate. The sequence affects risk, support load, and the credibility of the new product. Migrating the largest customers first proves scale but exposes the product to maximum stress before it's fully hardened. Migrating the smallest first is safe but may not surface real-world complexity.
Option A
Smallest/simplest customers first — minimizes early risk but may not surface the issues that affect larger customers.
Option B ★ Recommended
Most willing customers first (beta participants), then ascending by size. Beta participants have already accepted risk and are motivated to give feedback. The size-ascending order then gradually stress-tests the system before the largest migrations.
Option C
Largest customers first — proves scale immediately but exposes the product to maximum risk before it's fully proven.