The 80-Percent Question

There is a specific piece of business friction that most operators recognize but few name. You pay four figures a month for tools your team uses partially. Not because the tools are bad, but because they were designed for organizations twenty times your size. You bought the platform, and the platform brought its assumptions.

For a decade, this was accepted. There was no serious alternative. Building custom software was a luxury reserved for organizations with dedicated engineering teams and multi-year timelines. The economics did not close for anyone else.

That has shifted. Not universally. But enough that the honest question — is your current stack actually fit for your operation — deserves a fresh look.

The 80/20 problem

Take any enterprise-shaped CRM at €150 per seat per month. It supports opportunity forecasting for sales teams of thousands, multi-stage approval workflows across geographies, deep integration with a marketing automation suite you do not run. All of that surface area is there. All of it is priced in.

Your team, of twenty people, uses the contact list, the basic pipeline, and the notes field. Twenty percent of the surface. One hundred percent of the price.

This is not the vendor's failure. They built for the largest customer they can serve. Small operations pay the shape penalty.

The friction is not only financial. It compounds through every daily interaction. A new hire spends their first week learning navigation for features they will never use. An operator loses two minutes finding the option they need, buried under three levels of settings designed for enterprise governance. The team develops workarounds, spreadsheets, verbal conventions to compensate for the mismatch between the tool's assumptions and the operation's reality.

Multiply that friction across every daily user, across every daily interaction, across every month.

What "custom" means now

Historically, custom software meant starting from a blank editor and writing thousands of lines of code before the first useful feature appeared. That is not what custom means anymore.

Custom means composed. A base substrate — kernel patterns, evaluation frameworks, observability, brand and content discipline — is reused across every custom system a serious builder ships. Domain-specific logic sits on top. Agents replace substantial code that used to require dedicated engineering.

The result is a system built for your workflow. Not adapted, not configured, not "customized" in the sense that enterprise SaaS uses the word (a settings menu). Actually built for how your operation actually works.

The economics have shifted. Not enough to make custom trivial. Enough to make it viable for operations of ten to fifty employees, which used to be firmly buy-only territory.

What you gain

The first thing you gain is fit. Every screen is a screen your team actually uses. Every workflow reflects how work actually flows. Nothing to hide, nothing to route around.

The second thing is ownership. Your workflow logic, your data, your integration decisions. Not rented from a vendor who might change pricing, get acquired, sunset a tier, or shift direction in ways that no longer serve you.

The third thing is honest cost. Custom-built systems have real cost — engineering time, substrate investment, ongoing maintenance. The cost is real. But so is the enterprise SaaS cost, and the enterprise SaaS cost is often larger than it looks. Per-seat pricing scales with your team. Feature-tier upgrades appear every quarter. Forced migrations arrive when the vendor rethinks its lineup.

The honest fit question

Not every operation should replace its stack. Some genuinely work with their current tools. Some have no active pain, no expensive month, no daily workarounds. For those operations, the recommendation is straightforward: keep what works.

For the others — the ones where the current stack costs meaningful money each month and imposes daily friction — the question is worth asking.

Are you paying for a hundred percent of a platform surface to use twenty percent of it? Is the workflow your team runs actually reflected in the tool, or does the tool constrain the workflow you would prefer? Does a new hire spend more time learning your tools than learning your business?

If yes, the honest recommendation is not that custom will solve every problem. The honest recommendation is to do the arithmetic. Compare the current stack cost, including per-seat pricing scaled to your growth, plus the friction cost across your team, against what a purpose-built alternative would actually cost.

The number may surprise you. The custom-build option is not what it used to be.