SWTP Strategy¶

Updated: 2026-06-06

Status: This doc was authored as a strategic deep-dive on the SWTP→STE lead-gen mechanic. It remains accurate in thesis; the entity-name normalization (SWTP not "SP", Sedona Jeep Builders not "Sedona Jeep") has been applied in this 2026-06-06 refresh. See the canonical entity pages SWTP and STE for the current model.

Core insight¶

Superior Water Truck Parts (SWTP) is not a parts store. It is a lead-generation engine wearing a parts store as a costume. Parts margin is the bait; the asset is the customer list. Every transaction is a verified water-truck owner — the exact prospect STE's Iron Mesa USA and Superior Truck brands exist to sell trucks to. SWTP buys qualified truck buyers at a profit instead of paying for leads.

Implication: the customer record is the product. The order is metadata hanging off it.

Role of each entity¶

SWTP — marketing/CRM engine. Sells water-truck parts (China-direct sourcing). Every buyer is a known water-truck owner and therefore a scored truck-sales lead feeding STE's Iron Mesa USA and Superior Truck brands.
CTP — safety valve. A bad STE truck buy gets parted out through CTP. Used-parts revenue recoups the cost; secondary supply chain for SEQ/CTR rebuilds. See CTP as the safety valve.
STE — the truck-sales destination for SWTP's qualified leads. Dual brands: Iron Mesa USA (premium) + Superior Truck (standard).
Substrate — system-of-record data layer (Supabase). Owns inventory/parts/truck state. Rebuilt YMS and both storefronts query it directly.

SWTP and STE are separate INC corporations. SWTP captures customer data under its own brand; sharing that data with STE for downstream marketing requires explicit disclosure in SWTP's privacy policy or explicit customer opt-in to "ATG-family marketing." Without that, the data hand-off carries CCPA / FTC exposure. Flagged for MC-ATG to review.

Build decision: custom, not Shopify/Woo¶

Both SWTP and Cactus are catalog-and-quote / liquidation surfaces, not high-velocity consumer card checkout. Shopify's real differentiators — optimized consumer checkout, abandoned-cart recovery, fraud tooling — earn almost nothing here.

The deciding factor is integration. When the customer record is the asset, siloing it inside a transaction platform is the worst outcome. On Shopify the highest-value data (who owns what truck, what's wearing out, purchase cadence, fleet-size signals) lives behind their API; using it for truck marketing means syncing it back into the substrate anyway — adding a boundary, lag, and dependency to reach data that should have been owned natively. That is renting access to your own funnel.

Custom on the substrate's Supabase: every parts sale writes a truck-owner record into the same database the sales and marketing systems already query. A pump or tank-fitting purchase is a signal — active fleet, aging truck, reachable owner — i.e. a truck-sales trigger, in-system, real time, zero sync.

The build (locked)¶

Custom storefront on the substrate's Supabase. Parts purchase → truck-owner CRM record in the same DB.
Stripe for payments (Stripe Checkout / Payment Links) so card data never touches our servers — keeps us out of PCI scope without a walled garden.
Tax service (Avalara / TaxJar) only if SWTP ships taxable parts across state lines and triggers multi-state nexus.
Schema-first. Design the customer / truck-ownership table before the catalog. Treat the order as metadata on the owner record. The parts catalog is plumbing; the owner record is the asset.

Open items¶

Define the customer / truck-ownership schema: the fields that convert a parts buyer into a scored truck-sales lead.
Confirm multi-state shipping exposure to decide whether a tax service is in scope at launch.