Redline pays roughly $60,000/year for Mobiwork, the field-service CRM that 100+ Merchandising Specialists rely on every day for routes, check-in status, and client messaging. With AI-assisted development the build is no longer the hard part. The two questions that actually decide this are: which Mobiwork features does Redline truly use, and what does it cost to OWN a mission-critical mobile app for 100+ people — not what does it cost to write the code.
Redline runs its field operation on Mobiwork (mobiwork.com), a commercial field-service CRM, at a cost of ~$60,000/year. Three jobs ride on it every single day:
The COO's instinct is reasonable: $60k/year is real money, and a custom build could recover much of it. The CEO's instinct is also reasonable — "building a custom Mobiwork could take a hot minute." Both are half right, and the honest principal-engineering answer reframes the whole question.
So before a single line is written, the work is to decompose Mobiwork into the features Redline actually uses, separate core from nice-to-have, and be clear-eyed that we are not saving $60k — we are trading a $60k subscription for a smaller-but-permanent ownership cost. If that trade is favorable, it's a great build. If we accidentally rebuild the whole product, it is not.
The right move is not a clone. It's a feature-scoped MVP that replaces the highest-value module first, runs alongside Mobiwork, and proves itself before we cut the cord. Step one is honest feature decomposition.
Mobiwork is a broad field-service suite. Redline almost certainly uses a fraction of it. This is the audit that has to happen first; below is our best-guess starting hypothesis, to be confirmed in discovery.
| Module | What it does | For Redline |
|---|---|---|
| Mobile field app — status check-ins | Rep marks In-Transit / On-Site / Completed per stop, on a phone, in the field | CORE — the heart of the system |
| Mobile offline support | App keeps working with no signal; syncs when back online | CORE — lots are signal-dead spots |
| Route / day view (for reps) | Rep sees their ordered list of stops for the day | CORE |
| Push notifications | Route changes, reminders to check in, manager nudges | CORE |
| Dispatch / route planning (for managers) | Assigning stores to reps and ordering stops | CORE-ish — overlaps Route Optimization (see below) |
| Live status dashboard (managers) | Real-time view of who's where, coverage at a glance | CORE-ish — feeds RM updates |
| GPS / location tracking | Rep location, geofenced auto check-in | NICE-TO-HAVE — confirm if used |
| Client / dealer messaging | In-app comms tied to accounts | NICE-TO-HAVE? — Redline already lives in Slack/email; confirm real usage |
| Scheduling / calendaring | Appointment booking, time windows | CONFIRM — may not apply to lot merchandising |
| Forms / invoicing / work orders | Field data capture, billing docs | PROBABLY NOT — billing lives in Predian |
| Reporting / analytics | Built-in dashboards and exports | NICE-TO-HAVE — much already pulled from Predian |
| Admin / user management | Roles, onboarding, permissions | REQUIRED for any 100+ user system |
The minimum viable replacement is the three CORE rows above, wired into one pipeline:
FIELD REP (phone) MANAGERS (web)
───────────────── ──────────────
[ Today's Route ] [ Live Coverage Board ]
Stop 1 Dealer A ● Completed Region East: 18/22 stops done
Stop 2 Dealer B ● On-Site Region West: 11/19 stops done
Stop 3 Dealer C ○ In-Transit ◄──┐ ┌─► who's In-Transit / On-Site / done
Stop 4 Dealer D ○ — │ │ late starts, missed stops flagged
│ │
tap to advance status ────────────┘ │
works OFFLINE, syncs when back online │
│ │
▼ │
queued status event (idempotent) ──────┘
│
▼
API backend ──► Postgres (source of truth: stops, status, timestamps)
│
├──► push (FCM/APNs): route changes, check-in reminders
└──► feeds: RM Slack updates, Route Optimization, reportingEverything here is plain engineering — no AI magic is required for the CRM itself. The status pipeline is a queue of idempotent events from phones to Postgres, with a real-time read model for managers. The honest reason this is hard is not the data model; it's that it has to work on a dead phone in a back lot and never lose a check-in.
The MS Routes project already proposes an AI agent that continuously re-plans 100+ routes from Predian billing, Rippling home addresses, distance and traffic. That agent produces routes; this CRM is what delivers those routes to reps' phones and captures whether each stop actually happened. They are two halves of one loop:
A mobile-first field app, an API backend, one source-of-truth database, and a push pipeline. Deliberately conventional — for a mission-critical system, boring and proven beats clever.
A PWA (installable web app) is dramatically cheaper to own: no app-store review, no native build pipeline, instant updates, one codebase. It can do offline and push (Android well; iOS push is workable but historically fiddly). A React Native app gives the most reliable offline, native push, and a "real app" feel field reps expect — at the cost of two store listings, store review cycles, signing certs, and forced-update headaches.
Recommendation: start as a PWA to validate the pipeline cheaply; commit to React Native only if iOS push/offline reliability proves insufficient for 100+ daily users. Decide this in discovery, not by default.
Stops, status transitions, timestamps, and who-did-what are relational and audit-worthy. Postgres on RDS gives durability, point-in-time recovery, and a clean schema the Route Optimization project shares. Status events arrive as an idempotent queue from phones (each event keyed so a retry after a flaky sync can't double-count), and a read model serves the manager dashboard in near-real-time.
The architecture itself is small. The weight is in the non-functional requirements: offline correctness, push delivery, auth for 100+ users, and observability good enough that we know a sync is failing before a Regional Manager does.
Phased deliberately so Redline never bets the daily operation on unproven software. Each phase runs alongside Mobiwork; we don't cancel the subscription until the replacement has earned it. Build time is AI-assisted-fast and honest — but note the calendar is gated by real field piloting and store review, not by typing speed.
Sit with ops and 2-3 reps. Confirm exactly which Mobiwork modules are used daily, which are ignored, and what "good" looks like for check-in. Decide PWA vs. React Native. Output: a locked MVP scope and a build-vs-keep recommendation. This phase can conclude "keep Mobiwork" — and that's a valid, money-saving outcome.
The backend, Postgres schema, idempotent status-event API, and the manager live-coverage web dashboard. Seed routes manually (or from the route engine). Provable on a laptop browser before any phone work.
The PWA (or RN app): today's route, tap-to-advance status, offline queue with reliable sync, push for route changes and check-in reminders. The hard, non-negotiable work is offline correctness — the app must never silently drop a check-in.
One region's reps use both the new app and Mobiwork in parallel. Compare check-in completeness, sync failures, and rep friction against Mobiwork as ground truth. Fix what the field reveals. Do not cut Mobiwork yet.
User management/auth for 100+, onboarding flow, monitoring/alerting, a support runbook, and (if RN) store listings + review. Roll out region by region. Cancel Mobiwork only after a region has run cleanly on the replacement for a full billing cycle.
This build connects to systems Redline already has, plus net-new infrastructure that a custom mobile app requires (the items marked NEW are part of what "owning it" means).
| Source / Item | What we need | Used for |
|---|---|---|
| Mobiwork (current) | Read access / export of current routes, stop lists, status history; admin walkthrough of which modules are actually used | Feature audit, migration, shadow-pilot ground truth |
| Route source | Route assignments per rep per day — from Route Optimization engine, or Mobiwork export in the interim | The rep day-view |
| Predian | Store/dealer master data, billing context for coverage | Linking stops to accounts & reporting |
| Rippling | Rep roster, home addresses (shared with Route Optimization) | User accounts, dispatch context |
| Slack | Webhook/app to surface coverage status into regional channels | Feeding RM weekly updates |
| Apple Developer (NEW) | Apple Developer Program account ($99/yr), signing certs — if React Native | iOS app distribution + push (APNs) |
| Google Play (NEW) | Play Console account ($25 one-time) — if React Native | Android app distribution + push (FCM) |
| AWS account | RDS, ECS/Lambda, S3, CloudFront, Cognito, CloudWatch | Backend, database, hosting, auth, monitoring |
| On-call ownership (NEW) | Agreement on who responds when it breaks before routes start | Keeping a daily-critical system alive |
This is the section that actually decides the project — and the reason we lead with it instead of build time. The build is cheap now. Owning a field CRM that 100+ people depend on is not. Saving $60k/yr only counts if the run-plus-maintain-plus-support cost lands well below it.