Edge to Core.
Turning AI speed into product margin without breaking the Core.

Executive Summary

AI has made building a working version of software cheap, but it has not made maintaining it cheap. Today, a product manager or engineer can put a working feature in front of a customer in 48 hours.

The risk sits in what happens next.

This matters most at exit. Leaving custom code in the Core turns subscription revenue into support revenue, and buyers price support like IT services. As we model in Section 2, separating the two in a EUR 20M vertical software business can move enterprise value from roughly EUR 36M to EUR 54M on the exact same top-line revenue.

In most software teams, fast prototypes reach production through silent promotion. A proof of concept works for one client, sales promises it to the next prospect, and prototype code quietly slides into the Core R&D budget without an architectural review, a multi-tenant test, or a commercial contract.

Our rule is simple: never say no to the customer, just say no to funding their custom work out of R&D.

You do not need to walk away from services revenue to protect the product. You just need a hard line between what you build for every customer and what you build for one. Building on the product architecture Andy Hooper introduced at Fabric, that boundary sits across three layers:

• The Core is the multi-tenant product every customer runs, holding the data model, business rules, and versioned APIs. It is built once, sold across the customer base, and owned and supported entirely by Core R&D.
• The Enablers are the standard SDKs, APIs, event hooks, and configuration tools that connect to the Core. They let customers tailor workflows within the Core's data structure and rules, and are built and supported as part of the platform.
• The Edge holds everything built for a single test or a single customer. That covers two types of work: experiments (time-boxed prototypes in an isolated sandbox with no SLA) and customer-specific work (the custom integrations, workflows, and adapted configurations one client needs). The customer owns and supports its customer-specific work, or pays Professional Services (PS) to support it under a separate statement of work (SoW). Core R&D funds and supports neither.

Every experiment leaves the sandbox at one decision point, where it is either promoted into the Core, kept at the Edge as customer-specific work, or retired.

A prototype that misses the bar for Core does not have to be shut down. It can stay at the Edge as customer-specific work, either run by the customer on the Enablers or supported by PS under a separate statement of work.

How the system works

Early gates stay light, so builders actually use them. Registering an experiment takes minutes and checking that it is safely fenced takes a day or two, so a customer still sees working software in the same week.

When a pilot gets serious, tripwires agreed in advance, not argued case by case, force one decision: where it belongs and who pays for it. Product, engineering and commercial make that call together. The Tech Lead alone then decides how the code enters the Core.

How to Read This Playbook

1. Silent Promotion vs. Transparent P&L Boundaries

When building a prototype took six weeks, companies had to filter ideas before writing a single line of code. Now that AI tools can spin up a working prototype in two days, filtering up front wastes the very speed AI gives you.

The trap is silent promotion.

A weekend prototype solves a real problem for a flagship client, and sales immediately promises it to three prospects in the pipeline. Before anyone checks the plumbing, Core engineering inherits a fragile script that breaks on the next database migration. Worse still, your R&D budget ends up subsidising single-customer custom work for free.

Most of that cost never reaches a roadmap or an invoice. It is the invisible maintenance custom work leaves behind: the bug fixes, the single-tenant set-ups, the special branches, and the code that grows heavier with every exception.

The fix is not banning prototypes. It is making the cost of running software transparent:

• Let small pods build fast at the Edge.
• Put a hard commercial and technical gate between the Edge and the Core.
• Promote what many customers need into the Core. Give every customer the Enablers to configure the rest within the Core's rules.
• When a customer needs a workflow that does not belong in the Core, keep it at the Edge as customer-specific work. The customer owns it, PS only supports it under a separate SoW, and R&D never funds it.

2. The Valuation Math: Protecting Both SaaS Multiples and Enterprise Revenue

What custom code does to the multiple

Take a vertical software company with EUR 20M in revenue and 10 to 20 years of custom code sitting in its Core. Most of what customers pay each year is billed as support and maintenance: paying for access, updates, and fixes to a codebase bent around each individual account. In the legacy vertical software estates we have reviewed, most recurring revenue is billed as support and maintenance, and true multi-tenant SaaS is a small fraction of the book.

In due diligence, a buyer prices that revenue mix as IT services. Services-heavy software trades at 1.0x to 2.6x revenue, whereas multi-tenant vertical SaaS trades at 3.0x to 3.8x (Aventis). When you separate the codebase and the contracts, the valuation math changes completely on the exact same EUR 20M top line:

The result is roughly EUR 18M in additional enterprise value at the midpoint on the exact same revenue. (This baseline model assumes 70% of revenue moves to multi-tenant subscription once the Core is clean, with the remaining 30% valued at 1.0x services multiples based on external market ranges.)

Of course, you cannot fix this by simply relabelling invoices in the data room. Technical diligence inspects whether those subscriptions genuinely run on a single multi-tenant Core or on disguised customer forks. That is why the five gates matter for every new prototype today, and why legacy custom code in the Core eventually requires a structured rebuild (see Section 14).

What the evidence says about AI speed

• Task speed does not equal company throughput: Developers finish isolated coding tasks up to 55% faster in lab trials and complete 26% more tasks in field studies (GitHub/Microsoft). Yet DORA's 2024 and 2025 reports show that overall platform stability drops when review and deployment gates are not built to handle the extra volume.
• Code churn and security drift: Longitudinal data from GitClear shows short-term code churn and copy-pasted blocks rising sharply. Veracode found security flaws in 45% of AI-generated tasks, while Stanford researchers showed developers using AI assistants wrote less secure code while feeling more confident about it.
• The Commercial Trap to Avoid: Companies handle custom demand one of two ways. Some walk away from it, turning down EUR 1M in enterprise services to protect a EUR 300k licence. Others take the revenue and carry the maintenance inside R&D and support. The revenue is booked, but the custom code stays in the Core, and a buyer reads the recurring revenue as support rather than software, at the lower multiple. The answer is to take the revenue and price the boundary: services billed as services, maintenance on its own contract, and the Core kept multi-tenant. The full valuation argument is in the report listed at the end of this paper.

3. Resolving the Three-Way Executive Standoff

Every software company between 30 and 500 staff hits the same three-way standoff:

1. The Founder or CPO wants AI speed and feels Core engineering has become slow and defensive.
2. The CTO and Principal Engineers know 48-hour prototypes skip multi-tenancy and security, and they refuse to be paged at 2 AM for unvetted code.
3. Commercial, Sales, and PS leaders know that once an enterprise client loves a working prototype, taking it away kills the account.

A policy memo will not fix this.

You need a clear operational bargain across all three leaders. Product gets to build and test with live customers in days on the Edge. Engineering holds an unbreakable veto over how code enters Core, and Commercial gets a transparent price list to sell customer-specific Edge work whenever a feature does not fit the standard roadmap.

4. Three Layers: Core, Enablers and Edge

Building on the product architecture Andy Hooper introduced at Fabric, the estate is divided by who builds, who can change, and who supports each layer:

Where configuration ends: Configuring standard Enabler options is part of the platform and covered by standard support. Anything custom-built or adapted on top of those Enablers for a single customer sits at the Edge.

Two tests follow from this model. First, put into the Core only what you can sell to many customers; most legacy estates have put far too much there. Second, support triage must tell a product fault from a customer's own workflow: an automated report that stops is a Core ticket if the API failed, and the customer's if their own flow did.

5. The 8-Stage Lifecycle (Stress-Tested for AI Speeds)

AI coding tools write code in hours, but human decisions and customer adoption still take weeks.

The stage timings below separate actual AI build speed from human and customer waiting time:

6. Hard Tripwires, The Five Gates, and Commercial Routing

Hard Tripwires (When a free pilot stops being a free pilot)

Customer-specific work can live on the Edge long-term only if it is commercially contracted and ring-fenced.

An uncontracted discovery pilot must enter Gate 2 within 3 working days the moment it crosses any one of these seven tripwires:

1. A second customer asks for it.
2. It requires SSO, audit logs, or a formal security review.
3. It reads or writes live Core platform data outside an approved Enabler API.
4. It touches personal data (PII) or contract-sensitive commercial data.
5. Usage crosses 50 users or 3 customer departments.
6. A customer asks to include it in an SLA, renewal, or order form.
7. It hits the time limit or support drag threshold: reaching day 90 since Gate 0 (following a day-30 check), or pulling in Core engineers outside the Edge/PS pod to fix it more than twice.

7. Roles & Team Structure (~1 FTE Governance Overhead)

Running this model in a 25-engineer company takes roughly 1 FTE of combined governance time across existing senior staff. You do not need to hire process managers.

• Edge Builders (PMs, Domain Leads, Forward-Deployed Engineers): Build fast discovery prototypes on top of Enabler APIs.
• Edge Steward (~0.5 FTE part-time Staff Engineer or Delivery Lead): Clears Gate 1 containment in 1 to 2 days, tracks pilot clocks, and flags tripwires. The Steward checks sandbox isolation and data boundaries, not internal code style.
• Core Tech Lead (~0.3 FTE allocation): Owns the Architecture Verdict, oversees the Enabler API design, and ensures every Core merge has a named human owner.
• Professional Services team (funded by customer contracts): Builds and supports customer-specific Edge work under separate, client-funded SoWs, never out of the Core R&D budget.

8. Risk Tiers & Cutover Rules

The Stage 7 Cutover Rule: Once a promoted feature ships in Core, pilot customers get 30 days to switch over to the standard release included in their SaaS tier.

If a customer prefers to keep their bespoke workflow, it stays at the Edge as customer-specific work: they sign a PS maintenance schedule or take over maintenance on top of your Enabler APIs by Day 31.

9. Four Board Metrics That Matter

1. Unfunded Silent Promotions (Target: 0): Prototypes running in production without either a Core Gate 3 sign-off or a customer-specific SoW.
2. Edge Conversion Split (proposed target: ~25% Core, ~10% customer-specific work at the Edge, ~65% retired): Proves Gate 2 is filtering out weak ideas while monetising bespoke enterprise requests. This split is not externally validated. The retired share fits experiment evidence: at Microsoft, about two-thirds of tested ideas did not improve the metric they targeted (Kohavi et al., 2009). Calibrate it on your first two quarters.
3. Gate SLA Compliance (Target: >90% within the gate times): Gate 1 Containment within 2 working days, Gate 2 Routing within 3, and the Architecture Review within 5. Keeps governance fast enough that commercial and product teams never bypass it.
4. PS Custom Margin vs. Core Gross Margin (Target: >20% PS margin / >80% SaaS GM): Confirms customer-specific work is priced at full cost and never subsidised by Core R&D. Public SaaS companies with positive services margins typically run 15 to 25 points (Tunguz, 2015).

10. The 3-Year Cost & Revenue Model (25-Engineer Baseline)

To make the P&L trade-offs concrete, we model a 25-engineer software business over three years (3,450 person-weeks at a blended European loaded cost of EUR 1,800 per person-week; scale by 1.6x to 2.0x for UK, DACH, or US payrolls), producing 20 prototypes a year (60 over three years). The model counts new work only: the 60 prototypes started over those three years. Appendix A shows how each line is built.

Beyond recovering Core R&D capacity, routing roughly 10% of those prototypes (six enterprise workflows over three years) into full-cost customer-specific contracts turns an unmonitored R&D leak into a recurring profit stream:

11. Two Modelled Examples

• Case A: 75-Person Founder-Led Vertical SaaS (18 Engineers). The technical co-founder built six custom routing prototypes in Cursor for key accounts. Maintaining them for free carried invisible maintenance: bug fixes, single-tenant set-ups, and code that grew with every exception. Together with older custom code, it took 35% of every Core engineering sprint: 12 points from the six new prototypes and 23 points from custom code built up over earlier years. The Fix: Installed Gate 2 and the Enabler layer in 60 days. Two prototypes were rebuilt cleanly into Core, two were absorbed into standard Enabler configurations, and two stayed at the Edge as EUR 85k a year customer-specific PS contracts. New drag from prototypes fell from 12 points to under 2 within two quarters. The 23 points from older custom code stay until the Core is rebuilt, which is a separate programme with its own business case. With AI, that rebuild is now within reach; request the operating model and the case study to see its effect on margin and multiple.
• Case B: 280-Person PE-Backed Software Platform (65 Engineers). Pre-exit technical diligence flagged undocumented bespoke code paths that were dragging gross margin down by 6 percentage points. Walking away from custom work meant losing flagship accounts, including one client paying EUR 1M a year in services on top of EUR 300k in SaaS licences. The Fix: Moved all custom extensions onto strict Enabler APIs as customer-specific work under a ring-fenced PS business unit, while locking the Core platform behind Gate 3 Risk Tiers. The company kept 100% of its enterprise services revenue and presented buyers with a clean, multi-tenant Core SaaS P&L.

Both cases are modelled examples, not client results.

12. The First 90 Days: Installing the System Without Stopping Delivery

13. Four Questions Every Founder & CEO Will Ask

• “Won't five gates slow down our AI speed?” No. Gate 0 takes 15 minutes and Gate 1 takes 1 to 2 working days, so teams still put working software in front of a customer in the same week.
• “What if a flagship enterprise customer refuses the standard Core feature and demands their custom workflow?” It is a hard conversation, and it should not be the first one. Before any customer hears a price, do the cost-benefit work on each strategic account: revenue, margin, the real cost of their custom code, and their weight on the roadmap. Bring the largest accounts into the transformation plan early. Re-confirm what they need now, not what was written down years ago, and show them their own workflow running on the new Core. Then offer two or three priced options: the standard release, a configuration on the Enablers, or customer-specific work at the Edge under a PS contract. Customers accept change when they can see what they gain: faster releases, fewer outages, a product that keeps up. Some strategic accounts will justify an exception. Make it a decision with a price, not a default.
• “Why rebuild a working prototype at Stage 6?” Because an Edge prototype optimises for 48-hour discovery, while Core optimises for 5-year multi-tenant margin and security. Even when the Tech Lead rules Rebuild, the prototype saved weeks of written specs and proved commercial demand first.
• “Can the founder still code prototypes on weekends?” Yes. Founder prototypes are often the highest-signal experiments in the business. They just enter Gate 0 on Monday morning and follow the same commercial and architectural routing as everyone else.

14. The 12-to-24 Month Horizon: Why a Clean Core Matters More Than Ever (And What AI Cannot Do)

Be realistic about what AI can and cannot rebuild.

Re-architecting the underlying data schema and core platform of a mature EUR 9M+ software product still takes 12 to 18 months of hard graft, and that is before customer migrations. Typing the code was never the slow part. Untangling legacy customer data, reconciling edge-case requirements across hundreds of live accounts, and managing human change cannot be prompted away.

Where AI changes the game over the next 24 months is feature velocity on top of a clean Core:

• Spaghetti in, faster spaghetti out: If your Core is undocumented and polluted by silent promotions, coding agents will only generate technical debt faster.
• Fast assembly on clean boundaries: When your Core has documented schemas, strict tenant isolation, and a structured Enabler layer, AI coding agents can already build modular features that pass Adopt or light Refactor verdicts in days rather than weeks.
• What remains stubbornly human: Even as data migration scripts get faster to generate, customer migration is still the most expensive bottleneck in enterprise software. Getting an operations director to change their team's daily workflow, sign off on a cutover, and choose between standard Core or paid customer-specific work is a commercial and human governance problem.

Companies that master the Edge-to-Core boundary today will be the ones that turn AI speed into compounding enterprise value tomorrow.

Appendix A · How the Cost Model Is Built

Every line below is modelled. The external studies in the last column are cross-checks on the order of magnitude, not proof of the inputs.

Sources & Benchmarks

1. DORA / Google Cloud (2024 & 2025): Accelerate State of DevOps Reports
2. GitHub / Microsoft Research (Peng et al., 2023)
3. Cui et al. (2024), field experiments with AI coding assistants
4. GitClear (2025): AI assistant code quality research
5. Perry et al. (2023), Stanford: Do users write more insecure code with AI assistants?
6. Aventis Advisors: software valuation multiples
7. McKinsey (2020): Tech debt: Reclaiming tech equity
8. Pendo (2019): Feature Adoption Report
9. Stripe (2018): The Developer Coefficient
10. Kohavi et al. (2009): Online Controlled Experiments
11. Tunguz (2015): Professional services margins
12. Hooper, A. (Fabric): the Core, Deployment Enablers and customer-specific work product architecture this paper builds on.

About the author

Colin Whitfield is Founder and Operating Partner of Re-In-Essence. He works with founder-led and private-equity-backed B2B software companies on scaling, operational turnarounds, target operating models (R&D and Professional Services), and AI delivery governance.