What to standardize across a software portfolio, and what to leave alone

Standardize the vocabulary, not the values. In the design system behind this site, ninety-six token names are mandatory in all fourteen brands — and only six of them hold the same value in every one. The contract is shared. The design is not.

That ratio is the whole argument, so I'll put the measurement before the reasoning. I direct AI-driven design at Banyan Software across a portfolio of more than fifty vertical SaaS products, and I sell fractional design leadership to companies in roughly that shape — so I have an obvious interest in you believing portfolio design is a real discipline. The numbers below are counted from a repository you can inspect the output of, not from the portfolio under NDA, and I've been specific about the cases where doing none of this is the correct call.

The question, and why the standard answer is wrong

If you own a dozen software companies, someone has told you the products look inconsistent. They're right. The reflex is to commission a shared component library — one set of buttons, one set of tables, roll it out.

That fails, reliably, and it fails for a structural reason rather than an execution one. A component library standardizes the output. In a portfolio, the output is the part that legitimately differs: you bought fourteen products with fourteen customer bases and, usually, fourteen brands you paid for. Handing them one button is asking each team to either accept a look that isn't theirs or fork the library. They fork it. Within a year you have fourteen component libraries and an abandoned repo, plus the goodwill you spent getting agreement.

What can be standardized without destroying what you bought is the set of decisions each product is required to have made.

The measurement

Here is the system behind this site, counted on August 21, 2026. Fourteen brands, one per case study — a real portfolio at small scale, and the version I can show you rather than the one under NDA.

Read the fourth and fifth rows together, because that pair is the finding.

Ninety-six names are compulsory. Every product must answer what border-strong means, what surface-sunken means, what happens to primary on hover. Skip one and the build fails. And having forced all fourteen to answer, ninety of the ninety-six answers differ. The six that match are all corner radii — nested geometry, derived arithmetic rather than a brand decision.

So the standardization is total at the level of the question and almost nil at the level of the answer. Nobody was made to look like anybody else. What was eliminated is the thing that actually costs money: a product with no opinion about its own disabled state, decided ad hoc, differently, by whoever shipped last.

The four options, honestly costed

Option three is the one I'd argue for in most portfolios, and it is not free. The cost is a standing refusal: when a team needs a token that doesn't exist, the answer is to change the contract for everyone or do without. Most requests for a new name are requests to avoid a decision, and granting them trades one uncomfortable conversation now for fourteen small inconsistencies later. A lot of the job looks, from outside, like obstruction. I've written up the systems argument underneath this and why generation has to touch tokens rather than screens separately.

Post-acquisition: the first ninety days

The sequencing question comes up more than the design one. What you do with product fifteen on the day it closes:

1. Don't touch the interface. Nothing about a re-skin survives due diligence contact with a customer base you haven't met. The design debt is not the urgent debt.
2. Extract the contract, don't impose it. Write down what the acquired product already decided — its greys, its focus treatment, its density. You are auditing whether it can answer the ninety-six questions, not whether its answers match anyone else's.
3. Count the exceptions. The useful number after four weeks is how many values the product needs that the contract has no name for. Under five and it joins cheaply. Thirty and you've learned something real about integration cost, before anyone promised a synergy.
4. Adopt at the token layer only, on the next scheduled release. No migration project, no freeze. Products that get a dedicated "design system migration" line item are products where it gets cancelled at the first revenue wobble.

Step three is the one worth stealing even if you do nothing else. It converts "their design is a mess" — unarguable, unfalsifiable, and usually said by whoever has been there longest — into an integer somebody can be wrong about.

How many designers per product

This is the query I get asked most and the one with the worst available answers, most of which are ratios invented to justify a headcount request. I'm not going to publish my employer's staffing, and any ratio I did publish would be wrong for your portfolio anyway.

The structural answer: the ratio is the wrong instrument, because designers are not the scarce input. Deciders are. A portfolio can absorb an enormous amount of production capacity — that's precisely what AI-assisted workflows changed — and it chokes immediately on the number of people permitted to settle what's allowed to exist.

The evidence I have for that is a growth curve rather than a ratio. Scaling design at TheoremOne, ten people to twenty took forty-one months; twenty to fifty took eighteen. Same company, same market, nearly seven times the rate — and the difference wasn't recruiting. It was that by month forty-one there was somewhere to put people: a defined contract, so a new designer could be productive without a senior person adjudicating every grey. The longer version is here. Build the contract first and the headcount question mostly answers itself; hire against a ratio first and you buy a queue for the same three people's attention.

When to do none of this

Four cases, all common, and none of them appears in a pitch deck for portfolio design:

Under about four products. The contract costs a quarter to write. At three products the duplication is cheaper than the coordination, and anyone selling you a portfolio design system at that size is selling you their preferred engagement rather than your problem.

One product is most of the revenue. Staff that one properly and let the others be inconsistent. Portfolio-wide effort here is a rounding error dressed as strategy.

A holding period under eighteen months. Contract work amortizes over years. If the thesis is buy-and-flip, the interface you'd standardize is not the asset being sold, and a half-finished migration is worse in diligence than an honest mess.

Genuinely different platforms with no shared users. A contract that spans web and native pays off — this one ships CSS and Swift from a single source — but only where the same organization maintains both. Two unrelated products on two stacks share a spreadsheet, not a design system.

If your portfolio isn't one of those four, the work is real and it's mostly unglamorous: writing down decisions nobody wrote down, then defending the list. BlackLine is the closest public example of what that looks like inside one enterprise platform, and Navigate is what the four-week version produces when the answer is an audit rather than an engagement.

That audit is where I'd start, and it's the cheapest way to find out whether any of the above applies to you: fixed scope, two to three weeks, a written result you own. Rates and scope are here, and I'm at hello@product.inc. If you're in one of the four cases above, say so in the first email and I'll tell you so rather than quoting you.