The Revenue Architecture Manifesto

There's a pervasive assumption in B2B SaaS that revenue problems are performance problems.

Pipeline is soft? Push harder. Forecast missed? Inspect more. Conversion rates falling? Retrain the team.

This assumption is wrong. And it is expensive.

Design vs. Accumulation

The companies I've worked inside — early-stage to enterprise, pre-revenue to post-IPO — share a common pattern. The ones that scale well aren't simply executing better. They're built differently.

Their revenue systems are designed, not accumulated. Their operating models compound clarity instead of compounding exceptions.

Revenue architecture is the structural design of how a company generates, retains, and expands revenue. It sits upstream of tactics, tools, and individual performance. It determines:

• How decisions are made
• Who has authority to make them
• What happens when exceptions arise
• How incentives shape behaviour at scale

When architecture is intentional, growth amplifies what works. When architecture is accidental, growth amplifies what's broken.

How Architecture Happens by Accident

Most companies never design their revenue architecture. It happens to them.

A compensation plan inherited from the previous VP. A CRM configuration carried forward from the last stage. A pricing model patched together from three different eras of the business. Pipeline definitions that change by manager. Forecasting methodology that shifts under pressure.

None of these feel catastrophic in isolation. Together, they create structural drag — a persistent tax on every decision, every forecast, every quarter.

The most leveraged investment any scaling company can make is not a new tool, a new hire, or a new process. It is architectural clarity.

This manifesto rests on four pillars.

If governance is the foundation, incentive design is the invisible current running through everything.

Incentives shape behaviour more powerfully than strategy, more reliably than training, and more permanently than any process document.

That's not theory. It's 15 years of watching well-intentioned strategies fail because the comp plan rewarded something else entirely.

Two Examples That Repeat Everywhere

A VP of Sales announces the company is shifting to multi-year contracts. Better retention, higher LTV, more predictable revenue. Reasonable move.

But the comp plan still rewards annual bookings. Reps rationally optimise for one-year deals. The strategy fails. Not because of execution — because of design.

A CEO declares customer retention is the top priority. But CS carries no renewal quota, Marketing is measured on MQLs, and Sales comp is entirely new logo. Everyone nods at the all-hands. Nobody changes behaviour.

The incentives told them not to.

Compensation Is Architecture

Most companies treat comp plan design as a finance exercise — OTE, accelerators, quota thresholds. This misses the point.

Compensation is the most powerful architectural tool in a revenue system:

• What deals get pursued — reward revenue regardless of margin, and reps sell unprofitable deals. Reward new logos over expansion, and the install base gets neglected.
• How the forecast behaves — penalise misses but don't reward beats, and sandbagging becomes rational. The forecast becomes negotiation, not prediction.
• Where cross-functional friction emerges — pay Marketing on lead volume and Sales on closed revenue, and they'll be in permanent conflict about what "qualified" means. That's not a communication problem. It's an incentive design problem.
• Whether governance holds — if closing a deal outside the pricing framework has no consequence, governance is optional. The system learns that rules are suggestions.

Beyond Compensation: Authority and Ownership

Incentive design extends beyond pay. It includes authority boundaries — who makes which decisions, and what happens when boundaries are crossed.

Authority concentrated at the top? Decisions bottleneck. Authority distributed without governance? Decisions fragment.

Ownership is the other underexamined dimension. In too many companies, revenue-critical processes are owned by nobody — or by everybody, which amounts to the same thing.

Pipeline hygiene is "everyone's responsibility," which means it's no one's. Forecasting methodology is "collaboratively managed," which means it changes whenever someone senior disagrees.

Clear ownership is an incentive structure. When someone's name is attached to an outcome, the quality changes.

Designing Incentive Coherence

The goal isn't perfect alignment — that's fantasy. The goal is coherence.

Incentives across Sales, Marketing, CS, and Finance shouldn't be in direct conflict. Where they create tension — and some tension is healthy — that tension should be visible and intentional.

The audit asks:

• Does the comp plan reward the behaviour the strategy requires?
• Where do incentives across functions conflict — and is that conflict deliberate?
• Do authority boundaries match accountability?
• What behaviour would a rational person optimise for under the current design — and is that what the company needs?

If the answers are uncomfortable, that's the point. The alternative is a system where trade-offs are made by default, invisibly, and often against the company's interests.

This is the part of the manifesto that will be most controversial — and most consequential.

The SaaS industry built a multi-billion pound ecosystem on one premise: business-critical workflows require vendor platforms with annual contracts, implementation consultants, and dedicated CSMs. For two decades, that was largely true.

That constraint is dissolving.

AI has changed the build-vs-buy equation. Not in the way vendors are marketing it — wrapping a language model around an existing product and calling it "AI-powered." That's a coat of paint on the same architecture.

The real shift is that custom, business-logic-specific systems can now be architected, built, and deployed at a fraction of the historical cost.

What Can Be Replaced

I've personally architected and built AI-driven systems that replace platforms companies were paying six figures a year for. Not prototypes. Production systems handling real revenue workflows:

• Billing, invoicing, and revenue recognition — replacing Maxio, Chargebee, Sage Intacct (typically £100k+/yr). Systems that match your actual billing logic, not a generic model requiring months of configuration.
• Configure, Price, Quote (CPQ) — replacing Salesforce CPQ, DealHub, Subskribe (typically £100k+/yr). Pricing governance built around how your commercial team actually works.
• Contract lifecycle management — replacing Juro, Ironclad, PandaDoc (typically £50k+/yr). Contract generation, approvals, and renewal tracking for your specific requirements.
• Revenue forecasting — replacing Clari, BoostUp, Aviso (typically £60k+/yr). Models built on your pipeline data and historical patterns — not a vendor's algorithm trained on other companies.

Why Build Instead of Buy

The case for building isn't anti-SaaS on principle. It's architectural.

Off-the-shelf platforms impose their data model, their workflow assumptions, and their governance logic on your business. When your operating model evolves, the tool becomes a bottleneck.

Custom-built alternatives reverse this:

• Your business logic is the architecture — designed around how your company actually operates, not how a vendor thinks it should.
• Total cost of ownership drops — no annual licences, no per-seat pricing. Build cost typically recovered within 12 months versus the ongoing vendor contract.
• You own the system — no lock-in, no surprise price increases, no forced migrations. It evolves with your operating model.
• Governance is native — built into the system from the ground up, not approximated through vendor configuration.

When Not to Build

This is not a universal prescription. Buying remains right in clear cases:

• Core platforms — your CRM (Salesforce, HubSpot) is almost always better bought. The ecosystem value makes replacement impractical.
• Early stage — pre-Series A with five reps? You don't need custom billing architecture. You need to sell. Build when the vendor becomes the constraint.
• Commoditised workflows — if the tool does exactly what you need with zero configuration, the build cost isn't justified. The calculus changes the moment you start configuring around limitations.

The decision isn't binary. It's: where on the spectrum from off-the-shelf to fully custom does each workflow belong, given your stage, complexity, and total cost of ownership? That's an architectural decision — made by someone who has built and operated these systems, not by someone selling you one.