Generic vs. Vertical Architecture

Definition

Generic vs. vertical architecture is the platform separation principle for signal stack systems: build the data processing infrastructure once (ingestion framework, signal classification pipeline, firmographic enrichment, document generation engine, delivery + tracking, feedback/outcome loop) and configure per vertical (which data sources, what triggers, which decision-maker roles, outreach template, channel preference, conversion definitions). [src1] Each new vertical becomes a set of configuration files, not a new product build -- sharing 60-70% of infrastructure cost across verticals while preserving the domain depth that makes each vertical's signals commercially valuable. [src4]

Key Properties

Generic Layer (Build Once): Data ingestion framework, signal classification pipeline, firmographic enrichment engine, document generation engine, delivery + tracking system, feedback/outcome loop [src2]
Vertical Configuration (Per Market): Which data sources to crawl, what counts as a "trigger event," which decision-maker roles to target, template for the outreach package, channel preference, conversion definitions [src4]
50% Effort Rule: Each new vertical must require less than 50% of the engineering effort invested in vertical #1. If exceeded, the platform abstraction needs refactoring [src1]
Phase Gate: Platform extraction must not begin until 3 paying customers validate vertical #1 [src5]
Shared Economics: Single vertical = ~$500K-$2M ARR. Platform with 5+ verticals = each shares 60-70% infrastructure cost [src1]
Domain Advisor Requirement: Every vertical needs a part-time domain expert who validates signal taxonomy and outreach tone [src3]

Constraints

Platform abstraction must not begin until at least 3 paying customers validate vertical #1; premature platforming wastes engineering effort on wrong abstractions [src5]
Each new vertical must take <50% of the effort of vertical #1; exceeding indicates the abstraction is wrong [src1]
Every vertical requires a domain advisor to validate signal taxonomy; platform engineers lack industry context [src3]
Generic engine handles 60-70% of infrastructure; remaining 30-40% is genuinely vertical-specific [src4]
Config-driven verticals still require 2-4 weeks of domain-specific tuning for signal classifiers and templates [src2]

Framework Selection Decision Tree

START -- User building a multi-vertical signal stack
|-- How many paying customers in vertical #1?
|   |-- 0 --> Do NOT platform yet; focus on proving one vertical
|   |-- 1-2 --> Still too early; validate with 3+ customers first
|   |-- 3+ --> Ready to extract generic platform <-- YOU ARE HERE
|   +-- 10+ --> Platform should already exist; audit separation quality
|-- Does vertical #2 share data source types with vertical #1?
|   |-- YES --> High reuse potential; expect <30% new engineering
|   |-- PARTIAL --> Moderate reuse; expect 30-50% new engineering
|   +-- NO --> Low reuse; expect 50%+ new engineering; reconsider vertical choice
|-- Is the 50% effort rule met?
|   |-- YES --> Proceed with configuration-driven launch
|   +-- NO --> Refactor platform abstraction before adding more verticals
+-- Do you have a domain advisor for the new vertical?
    |-- YES --> Proceed with signal taxonomy design
    +-- NO --> Recruit domain advisor first

Application Checklist

Step 1: Validate Vertical #1 with Paying Customers

Inputs needed: Operational vertical with live signal detection, enrichment, asset generation, and delivery
Output: 3+ paying customers with measurable conversion data
Constraint: Hard gate: do not proceed to platform extraction with fewer than 3 paying customers [src5]

Step 2: Identify Generic vs. Vertical Boundaries

Inputs needed: Complete codebase audit of vertical #1, mapping each component to "reusable" or "vertical-specific"
Output: Architecture diagram separating generic platform from vertical configuration
Constraint: If more than 40% of the codebase is vertical-specific, the abstraction needs redesign. Target: 60-70% generic [src2]

Step 3: Extract Platform and Build Configuration Schema

Inputs needed: Architecture diagram, configuration requirements per vertical
Output: Generic platform with configuration schema; vertical #1 reimplemented as a configuration
Constraint: Vertical #1 must perform identically on the extracted platform; any regression means the extraction introduced bugs [src4]

Step 4: Launch Vertical #2 as Configuration

Inputs needed: Chosen vertical #2 (ideally sharing data source types with vertical #1), domain advisor, configuration files
Output: Operational vertical #2 with live signals and pilot customers
Constraint: Effort must be <50% of vertical #1; if exceeded, stop and refactor [src1]

Anti-Patterns

Wrong: Building a "platform" before proving any single vertical works

"Platform too early" is the #1 death pattern in signal-driven startups. Teams spend 6-12 months building abstractions for verticals they've never tested. [src5]

Correct: Prove one vertical end-to-end, then extract the platform from working code

The platform should emerge from refactoring a proven vertical, not from speculative architecture. [src1]

Wrong: Assuming each vertical is purely a configuration change with no engineering

Config-driven verticals still need 2-4 weeks of domain-specific signal classifier tuning, outreach template development, and conversion tracking setup. [src3]

Correct: Budget 2-4 weeks of engineering plus domain expert collaboration per new vertical

The 50% effort rule means less than vertical #1, not zero effort. [src4]

Wrong: Letting platform engineers define signal taxonomies without domain expertise

Engineers optimize for data pipeline efficiency, not commercial signal quality. A technically clean pipeline that detects wrong signals produces zero revenue. [src3]

Correct: Require a domain advisor for every new vertical, even part-time

The domain advisor validates which signals are commercially meaningful and what language resonates with buyers. [src5]

Common Misconceptions

Misconception: Vertical AI companies should start with a horizontal platform and specialize later.
Reality: Start deep in one vertical, prove the signal-to-revenue loop, then extract the platform. Horizontal-first approaches fail because they solve no specific customer's problem well enough. [src3]

Misconception: 60-70% shared infrastructure means verticals are 60-70% identical.
Reality: The shared infrastructure handles data plumbing. The remaining 30-40% -- signal taxonomy, outreach templates, conversion definitions -- is where all the commercial value lives. [src4]

Misconception: Once the platform is built, adding verticals is free.
Reality: Each vertical requires domain expertise, signal taxonomy tuning, and pilot validation. Signal stacks with 10+ verticals still budget $50K-$100K per new vertical. [src1]

Comparison with Similar Concepts

Concept	Key Difference	When to Use
Generic vs. Vertical Architecture (this)	Separates shared signal infrastructure from per-vertical configuration	Platform-stage signal stacks expanding from proven vertical #1
Multi-Tenant SaaS Architecture	Separates shared app infrastructure from per-tenant data isolation	Traditional SaaS with customer-level isolation
Microservices Architecture	Decomposes by functional service boundary	General application architecture; agnostic to vertical separation
White-Label Platform	Reskins one product for multiple brands	Cosmetic differences; no vertical-specific signal logic

When This Matters

Fetch this when a user asks about scaling a signal-driven business from one vertical to multiple, separating platform infrastructure from vertical configuration, deciding when to extract a platform from a working product, or estimating effort for additional verticals.