Hybrid isn't half-SPM and half-custom uniformly — it's SPM handling the standard 70–90% of comp and custom code handling the specific 10–30% that matters strategically. Done right, you get SPM's reliability on common cases plus custom flexibility where it actually moves the business. Done wrong, you get two systems, two maintenance burdens, and unclear ownership of every edge case.
This configurator walks through 10 comp-system responsibilities and asks which home each belongs in. The output shows your hybrid shape, estimated cost split, integration complexity score, and flags the typical design mistakes (critical functions split across both systems, custom doing work SPM does better, etc.).
The three options — and when each makes sense
SPM handles it
Choose SPM when the function is commoditized, compliance-sensitive, or audit-heavy. Rep statements, standard commission math, dispute workflow, audit trails — SPM vendors have solved these thousands of times. Building custom here is re-solving problems that are already fully solved in a product you're paying for.
Custom Overlay handles it
Choose Custom when the function is genuinely unique to your business, competitively differentiating, or a place where SPM constraints actively hurt. Product-specific crediting rules that change with every new launch. Integration with a proprietary internal system. Strategic-deal logic your finance team owns. Custom wins when flexibility is the actual requirement.
Split (SPM + Custom)
Choose Split only when a single function genuinely requires both — e.g., baseline calc in SPM with a custom post-processing step. Split should be rare. Every split function is a contract boundary that can break in production and a place where "whose bug is this?" becomes a real question. Target <3 split functions out of 10.
Hybrids fail most often by over-customizing, not under-customizing. A "hybrid" with 7+ custom overlays is really a custom build with SPM attached. The scorecard flags this: anything above 5 custom or 3 split functions gets a warning because you've likely duplicated effort or created fragmented ownership. Pure SPM (0 custom) is fine if your plan doesn't actually need overlays — hybrid isn't an end-state, it's a specific answer to specific complexity.
Hybrid Configurator
Assign each responsibility to SPM, Custom, or Split.
ℹ️ How this tool works +
The question it answers: For a hybrid SPM + custom architecture, which responsibilities belong where — and is my resulting split well-designed or quietly problematic?
What to do:
- Review the 10 comp-system responsibilities below.
- For each, assign it to SPM (product handles it), Custom (your engineering builds it), or Split (both participate).
- Enter rep count and annual SPM license estimate for cost sizing.
Cost estimation model:
- SPM annual cost = your entered license number (scales with rep count; Falcon's observed range: $300–$1,500/rep/year — validate against current vendor pricing for your specific requirements).
- Custom annual cost = $120K per custom function + $180K per split function (fully-loaded engineering, ~0.5 FTE per custom responsibility + integration overhead on splits).
- Total annual TCO = SPM + custom + 15% integration/maintenance overhead.
What you\'ll get back:
- Allocation summary (how many SPM / Custom / Split).
- Annual TCO estimate and cost per rep.
- Integration risk band (Healthy / Watch / Risky / Problematic) based on split count and custom ratio.
- Design-quality flags for common anti-patterns (custom doing commoditized work, too many splits, core functions split instead of owned).
Sample allocation pre-loaded (typical enterprise hybrid). Adjust to match your design.
Benchmarks, ranges, and default values in this tool reflect Falcon's practitioner experience across consulting engagements. They are directional starting points, not substitutes for market survey data. For binding compensation decisions, validate key figures against Radford, Mercer, Carta, or WorldatWork survey data for your specific geography, industry, and company stage.
Assign each responsibility to its home:
How to interpret the integration risk band
Healthy (0–2 splits, ≤3 custom)
Clean hybrid. Clear ownership for every function. Integration boundaries are narrow and well-defined. This is the shape most hybrids should aim for — SPM does the heavy lifting, custom handles the 1–3 differentiating functions, no grey zones.
Watch (3 splits OR 4–5 custom)
Defensible but needs discipline. Each split is a contract that must be documented and tested. Each custom function is a maintenance obligation. Quarterly review whether any split can collapse to single-owner or any custom can move to SPM configuration.
Risky (4+ splits OR 6+ custom)
You're heading toward a maintenance drag. Multiple split functions mean every bug requires two-team debugging ("is it SPM or is it us?"). Consider whether you should commit fully to custom for those functions or pull them back to SPM.
Problematic (5+ splits, or 7+ custom)
This isn't hybrid — it's custom with SPM attached, or two systems duct-taped. The cost is the worst of both worlds (license + engineering) without the benefits of either (SPM reliability gone, custom flexibility fragmented). Reassess the architecture entirely — likely the answer is "go fully custom" or "simplify plan to fit SPM."
A common trap: putting only audit + statements in SPM and building everything else custom. This looks like hybrid on paper but is really custom build with an expensive compliance addon. You're paying SPM license for ~10% of its value. Either commit to SPM for more functions or drop SPM and take the full custom path with a lighter audit tool. Don't pay SPM prices for custom architecture.
Designing a hybrid architecture?
We help SalesOps and Engineering teams design hybrid comp architectures that scale without becoming maintenance traps. Talk to us before you commit to the split.
Book a 20-minute consultation →FAQ
Falcon's estimate based on client engagements — costs vary significantly by geography, seniority, and company size. Each custom function typically consumes ~0.5 FTE year-round (200 hours implementation + 400 hours ongoing maintenance and iteration). Fully-loaded senior engineer = ~$240K/year. $120K per custom function ≈ 0.5 FTE. Split functions add 50% integration overhead on top.
Run the Architecture Decision Tree first to confirm hybrid is the right archetype for you. If it is, run this tool to design the specific split. If Architecture Decision Tree points to SPM or Custom, this tool isn't the right question — don't force a hybrid when pure wins.
Falcon's observed range: $300–$1,500/rep/year — validate against current vendor pricing for your specific requirements. For 120 reps at $600/rep = $72K. Use the low end if you're negotiating from scratch, the high end if you're buying a premium vendor with heavy integration support. You can re-run with different numbers.
These 10 are the standard enterprise comp-system functions — they cover 90% of what any sales comp architecture needs to do. If your business has an unusual 11th function (e.g., joint-venture revenue sharing), treat it as a custom overlay and add $100K–$200K/year to the custom cost estimate.