Four questions worth answering before your team starts. And a case for building more, not less.
I've had a similar version of the same conversation more than a dozen times in the past year, with clients and practitioners alike. It opens the same way nearly every time. Someone's IT team has built a working prototype of a tool the company currently pays for. They built it fast, with AI tools.
And it works.
Let’s sit with that for a second. Most companies I talk to are sitting on a decade’s worth of potential software ideas that never got built., mostly because it couldn’t win a priority fight against a roadmap of backlogged items. AI’s changed that calculus. Teams that have said "not this year" every year since 2016 are shipping things in a couple of weeks, and I think that's great.
The vendor reflex at this point is to get dismissive – to say “those tools probably look good, but they won’t really work.” I won’t say that, mostly because it’s just not true. The prototypes are real. GitHub's controlled trials have clocked productivity gains as high as 55 percent, which roughly matches what R&D leaders tell me privately. If your team says they can build a working version of something you're paying for, you should (mostly) believe them.
And being honest: vendors earned some of this skepticism. We've spent twenty years telling buyers that everything we sell is strategic, differentiated, and impossible to replicate. Some of that was true. Some of it was marketing. If your instinct right now is to re-examine what you're paying for and why, that's a healthy instinct, and I'd rather meet it directly than pretend it's misplaced.
So the question now isn’t whether your team can build working things. Often they can. The question is “which things should they build?” It turns out that that sorting problem is harder than it looks. Mostly because whatever will make a system expensive to own five years from now is almost never visible in the version you see in week three.
What AI Has Changed, And What It Hasn’t
AI’s compressed the cost of version one. It has done very little to the cost of version forty.
The benchmarks here have barely moved in decades. Something like 60 to 80 percent of a system's lifetime cost lands after launch: maintenance, integrations that snap when an upstream system changes, compliance updates, edge cases nobody scoped, and the steady sediment of "we'll fix that later." AI made the cheapest part of that lifecycle cheaper still. Which is fine, and it's a real gain. It just isn't the gain most build cases are implicitly claiming.
For a good chunk of your portfolio the math genuinely has flipped. Internal portals, approval workflows, reporting layers, data tools, the app someone in finance has been asking for since 2019. Build them. If one breaks, somebody fixes it Tuesday and nothing catastrophic happened.
The error is assuming the flip is uniform. It isn't. Some software carries properties that make it expensive to own no matter how cheaply it got born, and a prototype is precisely the artifact in which those properties stay invisible.
Four Questions That Tell You Which Kind You're Looking At
So how do you know whether you’re looking at a build whose real problems will surface in the future? You might want to start by asking these four questions. (To be clear: these have nothing to do with any individual vendor’s offerings. They’re about what your business needs from any piece of software.)
Does your tool have to be right, or just useful?
Most software fails gracefully. A dashboard that's off by three percent is a mild irritation somebody eventually notices.
Some software doesn't fail gracefully. A commission calculation that's off by three percent is an underpayment to a seller who now distrusts every number you hand her, a clawback conversation, a bad accrual, and an auditor with a follow-up question. There's no "mostly right" tier available.
Does it have to remember?
This is the one that gets missed, and it's the most technically consequential of the four.
Most business systems only need to know what's true now. Ask your CRM who owns a territory and it will tell you, accurately, as of this morning. Ask who owned that territory on March 14 of last year and it will hand you either the wrong answer or no answer, because it was never built to answer that question. It overwrote the old value.
Systems that administer compensation have to know what was true then. A deal from two quarters back gets reversed, and now the system has to rebuild the world as it stood the day that deal closed. Who owned the territory. What the reporting hierarchy looked like. Which plan version was in force. Where the rep sat on her attainment curve, and whether removing this deal drops her under an accelerator threshold she's already been paid at, which means the reversal was never about one transaction in the first place.
Every one of those facts has changed since.
Maintaining a complete, date-effective version of your own past is a different engineering problem from knowing what the status is today. Not a harder version of the same problem. A different one. And a prototype built against current-state data will never surface it, because everything will work beautifully until the first retroactive adjustment.
Does it have to explain itself?
Producing the right answer and proving the answer was right are two separate capabilities, and only one of them turns up in a demo.
Auditors don't take output on faith. They want inputs, the rule version that governed the calculation, the org state at the time, the approval chain, and the ability to reproduce that exact figure three years later. Your reps want roughly the same thing, minus the vocabulary. If answering "why was I paid this?" requires an engineer to open a log file, what you've built isn't a system. It's a monthly forensics project whose cost scales with headcount.
How often do the rules change?
Some systems get built once against requirements that hold steady for years.
This isn't one of those. New product. Pricing shifts to consumption. Territory realignment. Quota redesign. A change to how credit splits between the direct seller, the overlay, and the partner. A mid-year accelerator. A two-week contest aimed at one behavior in one segment.
On a platform, each of those is a configuration change. On a build, each one is a ticket in a queue, behind everything else engineering owns.
Where This Leaves Sales Performance Management
You should be asking these four questions before you build anything internally. Run them against most internal needs and you’ll get a range of answers. Run them here and it's a very clear “yes” to all four, none of them close.
In fact, I'd widen the frame. Honestly, "commission software" undersells what we're talking about in SPM. Territory design. Quota setting. Crediting rules and date-effective hierarchy. Plan structures, contests, SPIFs. The calculation engine beneath all of it, and the reporting that tells leadership whether the design is doing what they hoped it would. Sales performance management is the category label. Functionally, it's commercial strategy, executed.
Which brings me to the comparison I find most clarifying.
Almost nobody proposes building their own payroll engine. Not because it's out of reach technically, since at some level it's arithmetic. It's that everyone grasps, without needing it explained, that a regulated retroactive auditable system where mistakes land in people's paychecks is a poor place to learn on the job. Payroll gets that respect because its failure mode is legible to everybody in the building.
SPM has the same structural DNA. Integration-heavy, retroactive by design, audit-critical, and wrong answers show up in someone's pay. It just doesn't carry payroll's reputation, so it gets evaluated more casually than it deserves.
There's also a dimension payroll doesn't have. Payroll executes a decision that's already been made. SPM is where the decision gets made, argued over, changed, and remade, several times a year, under pressure, while the current cycle is still running.
The People Who Already Know All Of This
If you run comp or sales ops, none of the above is news to you. You've lived all four questions, usually around 11pm, two days out from a payroll deadline.
One observation about that work, since I don't think it gets said often enough.
The jobs most exposed to automation are the ones built on structured, repeatable workflows. Consistent inputs. Rules written down somewhere. A right answer knowable in advance. Comp and sales ops is close to the inverse. There's no standard template for plan design. The rules contradict each other on a regular basis. A good part of the job is adjudicating situations nobody anticipated, and much of the rest is translating what a CRO says he wants into something that will actually produce the behavior he's describing rather than the behavior he literally asked for.
AI will change parts of that job and I'd welcome most of it. The reconciliation grind. Data cleanup. The first draft of a model. What it doesn't touch is the judgment, and in this discipline the judgment is the job.
When people say a system like this can't simply be generated, the claim underneath is that the expertise required to run it was never written down anywhere. It lives in the people running it.
The Cost Nobody Models
Everything above concerns cost of ownership. The bigger number is optionality, and I have never once seen it in a build business case.
Compensation is the fastest instrument leadership has for converting a decision into behavior across a large, distributed sales organization. Strategy conversation on Monday, different activity in the field by the end of the quarter. A competitor moves, a product launches, a segment stalls: this is the lever you reach for.
If you’re working in a home-built system, that lever runs through your engineering backlog. That again changes the decision tree. Because in that case, the question stops being "what's the right incentive here." Instead, it becomes "when can the team get to it?" If you’re in charge of any part of the commercial enterprise, this isn’t the obstacle you want to be facing.
I've watched organizations stop requesting plan changes altogether. This isn’t because the changes weren’t needed. It was because asking had become expensive. So people quietly lowered what they asked for.
You don't lose money on that one. You lose speed, which was the entire point of having the instrument.
What I'd Actually Tell You
Build more than you used to. The tools are legitimate, the backlog is real, and most IT organizations have an opportunity in front of them they didn't have three years ago.
In fact, I'll go further, at some risk to my own commercial interests. If your comp program is genuinely simple — one team, flat rate, no overlays, no partners, nothing meaningful in the way of retroactivity — then build your comp tool internally. You'll be fine. You shouldn't be paying a platform for that, and I'd rather say so than pretend every company needs what we sell.
If you're in the other case (the more complicated scenario), run the evaluation with the rigor you'd bring to any multi-year capital decision, and make sure it spans day one through year five rather than the demo. Teams that come through this well tend to pressure-test the same short list before committing: retroactive recalculation at production scale, date-effective credit assignment across multiple entitled parties, quota credit versus commission credit, audit reproducibility and multi-year retention. Migrating off an existing platform adds two more, the parallel-run plan and what becomes of your historical record after cutover.
We've written those questions up properly, aimed at architects and IT leaders rather than at buyers. This isn't a sales document. It's the list of things we've watched genuinely capable teams discover in month fourteen instead of month two. If your organization is going through this evaluation, I'd rather your team have it at the start than come across it later.
Conclude that a build is right for you, and at least it's a decision made with the full picture. Conclude the opposite, and that's something we intend to keep earning.
Either way the same thing holds. This is the best moment in the history of enterprise software to build something yourself. It's also the moment to be most deliberate about what you don't.