The 85/15 rule.
The fastest thing I can tell a new client is this: I'm not building your platform from scratch. I'm adapting a platform that's already in production, already handling real traffic, already processing real leads. The question isn't "can this work for my category" — the Anchor build answered that. The question is "what changes to make it mine."
The answer is less than you think.
When I started the Anchor build, I made every architectural decision with one constraint in mind: nothing in the platform logic can be specific to the product category. The catalog holds one product type now. It needs to be able to hold insurance policies, real estate listings, equipment, RVs, or individual salesperson profiles without tearing out the foundation.
That constraint shaped every decision from the CRM schema upward. It's why leads are [client]_leads with a generic status enum instead of a category-specific table with a category-specific field at the top level. It's why the customer portal tabs are defined in a config array instead of hardcoded HTML. It's why the email template system takes a variable block structure instead of baking a product name into the subject line.
The result: 18 months of building produced a core that's transferable.
I mapped every system in the platform to one of three buckets: stays as-is, config change, or new build.
| System | Category | What changes |
|---|---|---|
| CRM schema (3-table) | Stays as-is | Nothing. Lead, conversation, owned_unit is category-agnostic. |
| Lead capture forms | Config change | Form fields + copy reflect the vertical. Routing logic unchanged. |
| Source attribution | Stays as-is | UTM/referrer/page is universal. |
| Email engine (7 modules) | Config change | Templates, sender name, sequence copy. SMTP infrastructure unchanged. |
| Customer portal structure | Config change | Tab labels + content. OAuth flow unchanged. |
| AI layer | Config change | Voice guide + product vocabulary. Cost architecture unchanged. |
| PWA / mobile | Config change | App name, icons, push notification copy. Service worker unchanged. |
| Design system | New build | Brand palette, typography choices, logo. CSS variable values change; variable names don't. |
| Catalog / inventory | Config change + new build | Custom fields for the product type. Core CPT infrastructure unchanged. |
| Marketplace syndication | New build | Different marketplaces per vertical. Fan-out architecture unchanged. |
| Compliance layer | New build | Per-vertical, no shortcuts. |
| Hosting / CDN / security | Stays as-is | Same Cloudways + Cloudflare Pro stack. |
"Config change" means editing a configuration file or swapping template copy. It doesn't mean writing new logic. "New build" means writing new code — but against the existing architecture, not from scratch.
The infrastructure layer (PHP 8.2, Cloudways, Cloudflare, OPCache, WAF, backups, UptimeRobot) transfers unchanged.
The data layer (3-table CRM schema, JSON activity timeline, 8 query helpers, lead status state machine) transfers unchanged. A lead is a lead. Status flows from new → contacted → qualified → closed_won/lost regardless of the vertical.
The communication layer (7 email modules, Brevo SMTP setup, nurture sequence logic, inbound listener, SMS rail design) transfers unchanged. Templates are swap-outs.
The portal architecture (OAuth, tab routing, document exchange, seller-buyer binding) transfers unchanged. Tab labels change. The authentication and session model doesn't.
The AI layer (central wrapper, per-call-site model routing, prompt caching, daily cap, natural-language query engine) transfers unchanged. The voice guide is new per client. The cost architecture is not.
Catalog schema: Custom fields per product type. A marine dealer needs make, model, year, hull material, engine hours, HIN. A real estate team needs bedrooms, bathrooms, sqft, lot size, MLS ID, listing status. An equipment rental company needs category, weight class, operating hours, availability calendar. Each is a set of custom meta fields registered against the custom post type — same CPT architecture, different field definitions.
Marketplace feeds: The fan-out architecture is inherited. The adapters are new per vertical — each marketplace has different required fields, image specs, and API authentication patterns. These are new but they're plugged into the same fan-out infrastructure.
Compliance layer: Not transferable at all. Insurance has TCPA, state licensing restrictions, and carrier-specific consent requirements. Real estate has RESPA, Fair Housing, and MLS terms. Healthcare-adjacent has PHI scope questions. This gets its own lesson (12.3).
Design palette: The CSS variable system is inherited. The values change. Brand color, heading typeface, border radius preferences, logo — all new. No redesign from scratch, because the variable system means I'm changing values, not rearchitecting the design language.
The alternative to a transferable platform is a rebuild every time. Agency model: every client gets a fresh start. That's why agencies charge $200K and take 18 months. From-scratch means you're paying for invention.
The GAP Industries model is adaptation. You pay for the 15% that's truly yours, plus ongoing operation. The 85% is overhead already absorbed.
The practical implication for a new client: the scoping conversation isn't "what do we need to build." It's "what do we need to adapt." The deliverables list is mostly catalog schema definition, marketplace adapter identification, compliance scope documentation, and design direction. The build can start from there on day one.
The Anchor build is why the 85/15 rule exists as a rule rather than a hypothesis. I built the platform with the intent to transfer it. Everything that got hardcoded to the original product category got refactored out within the same phase.
The test: when I started the second vertical (an insurance lead-gen platform), how much of the Anchor codebase was usable? The communication layer, portal architecture, AI layer, hosting stack, and security baseline transferred without changes. The catalog schema was replaced with an insurance product schema. The marketplace adapters were replaced with insurance aggregator connections. The compliance layer was rebuilt for TCPA and state licensing. Design palette was new. That's the 15%.
The second build launched in weeks, not months. That's the point.
[client]_leads not [client]_product_leads. Status enums that work for any sales pipeline, not for one category specifically. The discipline costs nothing at authoring time and pays every time you adapt the platform.Every lesson stays free — no account, no paywall, no email gate, ever. But if you’d rather have this system standing on your business than wire all 48 lessons yourself, leave your email. We’ll send you a direct line to a build — and you’ll be first to hear when we add new tools to the curriculum.
None of this gates a single lesson. The curriculum was free before you got here and it stays that way.
You came here to understand the system, and now you do. If you’d rather have it standing on your business than spend the next three months wiring it yourself, GAP Concierge is the same architecture from these lessons — a white-label AI agent that knows your catalog and captures your leads — set up for you, from $97/mo.
See GAP Concierge →