Shared VisitSend engine
Core improvements to auth, quotes, jobs, visits, rewards, areas, reporting, and security ship once and can be pulled into every client app.
Custom client apps
A branded app for the company that needs more than a standard plan.
Maintenance Magicians becomes a client on the platform: its app can keep custom commissions, contractor accounting, territory rules, and brand-specific screens while still receiving shared VisitSend updates.
Client workflow layer
Custom behavior lives behind feature flags, settings, and client-specific modules so Maintenance Magicians can keep its contractor-heavy workflow.
Release channels
VisitSend can receive product updates first, while custom apps get reviewed releases with private notes and extra verification.
Client separation
Platform product and custom clients stay visible side by side.
Source
Shared VisitSend Core
Delivery
shared app tenant
Review
client-reviewed release channel
Custom scope
6 thin modules
NameStatusModelUpdate channel
Maintenance Magicians
Custom App
Incorporated Custom App tenant
Contractor-heavy, commission-driven, territory-aware Growth Operator configuration
Shared VisitSend engine plus Maintenance Magicians custom workflow layer
VisitSend Core
Starter / Team / Growth / Multi-Location / Franchise System
Platform product
General trade operations for people, contractors, rewards, areas, locations, and franchises
Primary product releases
Long-term operating rule
Stop syncing forks. Classify every change by ownership.
New work starts in shared core unless it is clearly configuration or a thin client layer. Manual separate forks are a temporary migration bridge, not the release model.
Shared VisitSend Core
VisitSend repo
If a change would help normal VisitSend tenants and MM, build it once in core first.
Tenant Configuration
business settings, feature flags, plan/model metadata
If a behavior can be expressed as settings, flags, or seeded business data, do that before adding code.
Thin Custom Client Layer
custom app manifest plus client-reviewed release channel
Custom code must depend on shared core APIs and stay isolated behind feature flags, manifests, or custom app records.
Manual Separate Fork
blocked pattern
Do not choose this for new work. Use only as a temporary migration bridge with an explicit retirement note.
1. Core first
Land shared engine work in VisitSend Core with tests and docs before client-specific wiring.
2. Configuration review
Decide whether the customer difference is plan/model/feature-flag/business-setting data.
3. Custom layer review
Add only the small client module that cannot be represented as configuration.
4. Client release
Record release-channel status and verify against the custom client before rollout.
Brand and domain
Client-specific logo, colors, app name, domain, email sender, and onboarding copy.
Permission model
Custom roles, feature gates, and rollout permissions without weakening platform security.
Workflow modules
Custom calculators, forms, dashboards, exports, importers, and client-specific operational logic.