The n:n Company

I keep coming back to this when looking at AI-native software companies.

There is plenty of discussion about gross margins, wrappers, model defensibility, and whether a product is really software or partly a service. All fair questions. But I think they miss a more basic change in how these companies are being built.

The old software model was straightforward: build one product and sell it to as many customers as possible. Software took long enough to build that a good product could give you several years of advantage. The product was the asset; the commercial job was to spread the R&D cost across a growing customer base.

That describes most of the SaaS companies of the 2010s. Find an ICP, understand one painful problem, build for it, and repeat the sale. Additional products came much later, usually after the first product had become a substantial business of its own. Salesforce, for example, spent roughly a decade centered on sales CRM before the broader suite really emerged.

AI is changing that sequence.

Building the next product is becoming cheaper and faster, while earning trust inside a company remains difficult. In many AI-native businesses, the scarce asset is therefore not the code. It is the customer relationship: access to the workflow, credibility with the buyer, and enough context to understand what should be built next.

I have started thinking of these as n:n companies. They do not build one product for many customers. They enter through one product, learn from a group of customers, and then build several products across those relationships.

The distinction matters because it changes the economics. Instead of mainly amortizing R&D across customers, you begin to amortize CAC across products.

Once a company has earned its way into an account, the second product should be much easier to sell than the first. The customer already knows the team, has seen the technology work in its own environment, and is often the one suggesting the next use case. The first contract may be relatively small, but it creates an option on a much larger relationship.

This sounds like land-and-expand, because in one sense it is. Veeva, Toast, ServiceTitan, and many others built large businesses by starting with a wedge and expanding around it.

What feels different now is the timing.

Historically, multi-product expansion was a growth-stage project. Today, I am seeing companies consider a second or third product while they are still at seed, sometimes within the first year of going live. Work that previously required several product teams and a long roadmap can now be tested by a small team in weeks.

That does not mean every customer request should become a product. Early customer pull can also drag a company into a collection of bespoke projects with no coherent strategy. But when the same adjacent problem appears across several accounts, the signal is hard to ignore. The roadmap starts to emerge from the relationship rather than being fully designed in advance.

There seem to be two credible ways to acquire that relationship.

The first is a narrow, inexpensive wedge: something useful enough to close quickly, but small enough to avoid a six-month procurement process. On a standalone basis, the initial ACV might not look exciting. Its value is partly in what the company learns and what it becomes eligible to sell next.

The second is the FDE-style engagement. Start with a large, messy problem, put technical people close to the customer, and build around the customer’s actual environment. From a traditional SaaS perspective, this can look uncomfortably like consulting. Sometimes it is consulting. The important question is whether the work compounds.

If customer one’s bespoke request becomes a reusable capability for customers two through ten, the delivery work was also product discovery and R&D, funded by the customer. Palantir is the obvious reference point here: deployment work did not remain a series of isolated projects; parts of it became repeatable infrastructure.

The cheap wedge and the large bespoke deployment look like opposite strategies. In practice, both are attempts to earn the same thing: enough trust and workflow access to expand.

This also changes what I look for in an early team.

“Can they build it?” still matters, but it is less discriminating than it used to be. A growing number of teams can produce a credible first version quickly. Far fewer can get into the right accounts, understand what is actually happening there, and turn one successful deployment into a broader product relationship without losing focus.

That is one reason domain-expert founders have become so interesting. Their advantage is not only that they can write a better product specification. They know how buyers talk, where projects get stuck, which workflows matter, and whom to call first. They often arrive with some of the trust that a generalist founder would need years to earn.

None of this means technology has stopped mattering, or that every AI company should launch five products in its first year. A weak product does not become a good business simply because it sits inside an account. And undisciplined expansion is still undisciplined expansion.

But I do think the underwriting question is shifting.

For founders, the landing contract should be evaluated not only by its initial revenue, but by the quality of the account, the depth of workflow access, and the credible paths to expansion. The goal is not to chase every adjacent request. It is to learn faster than competitors which requests are pointing toward a repeatable product.

For investors, the team question is becoming less about whether the founders can ship a first product and more about whether customers will trust them with the second problem. Do they have the credibility to enter the account? Can they distinguish a one-off request from a market signal? Can they deepen the relationship without turning into a services firm?

The simple version is this:

The old software company built a product and searched for customers.

The AI-native company may land a customer and, through that relationship, discover a much larger set of products.

Not every company will fit this model. But for the ones that do, the customer relationship is no longer just a route to revenue. It is the asset the rest of the company gets built around.