I don't want seventeen businesses to market

I want AI to help me build more products. I don't want seventeen separate fights for customers.

If every new app needs a different audience, a different pitch and a different way to reach people, you've volunteered to start over seventeen times. The code might be cheap. Getting someone to care is still your problem.

The case for a portfolio is getting more interesting, though. Bannerbear founder @yongfook wrote that he'd changed his mind about focusing on one product: AI makes running several more feasible, and betting everything on one app feels risky when a new model or a clone could threaten it.¹ HeadshotPro founder @dannypostma added that founders should use their products to cross-promote each other.²

I'd make that decision before building the next product.

Which customers already trust you with something, and what else are they trying to get done? That answer should have a serious vote in what you build next. Otherwise, cross-promotion becomes a collection of footer links between products whose only connection is your name on the invoices.

Give the second product a reason to exist

Someone paying you to send email might also need to understand why it isn't arriving. You already have a reason to talk to that person, and the problem can become visible while they're using what you've sold them.

That's the relationship between Bento and Tatami. Bento handles email marketing and transactional email. Tatami monitors delivery. Bento gives its customers access to Tatami to investigate failed or delayed emails.³ Tatami can receive delivery records from Bento, so the customer can investigate using data from the tool already sending their emails.⁴

The connection does useful work. The sender has an email that failed to arrive; the other product helps investigate what happened. A customer doesn't have to develop an interest in the founder's portfolio before the second tool becomes relevant.

I'd look for that relationship before I looked for another idea I could ship by Friday.

It also changes how I'd introduce the new product. An announcement to every customer asks everyone to work out whether they care. A recommendation while someone is investigating failed emails already has a reason behind it. The introduction needs to explain what they can do next, with the information they've already got, and what using the second product would cost them in setup and money.

Putting more logos in the navigation doesn't answer any of that.

You can share customers without sharing every product

Sometimes the right answer is a feature in the product people already pay for. If I have to make the original product worse to create demand for its sibling, I've probably invented a billing scheme rather than a useful business.

A separate product makes more sense to me when people can want it without wanting the first one. Tatami also supports email providers including SendGrid, Mailgun and Postmark.⁵ That gives the distinction some substance: Bento can introduce it to relevant customers, while someone using a competing sender can still have the same monitoring problem.

Existing customers can help a new product get started without defining everyone it will ever serve.

Before building, I'd talk to the customers whose work keeps running into the proposed problem. Show me how you're dealing with it today. Where do you leave our product, and what do you open next? If the answer is an awkward spreadsheet or a second service they're unhappy with, there's something to investigate. If nobody needs the next thing, access to their inbox won't manufacture the need.

That conversation could also tell me to improve the first product. I'd take that result over another launch I now have to keep promoting.

Be honest about what you're diversifying

There is a catch in building several products for the same customers: you're still exposed to those customers having a bad year. And if every product depends on the same AI capability staying scarce, more product names won't protect you when that capability gets cheaper.

So I wouldn't sell this to myself as eliminating risk. I'd be choosing to reuse customer knowledge and access, while accepting some shared exposure. Truly unrelated businesses might spread those risks further, but then I have to earn my way into unrelated markets. That's a different amount of work, even if an agent writes the code.

I'm happy for the software to get easier to build. It gives us more choices. I'd use that freedom to go deeper into work our customers already need help with, instead of treating every new idea as an excuse to abandon the advantage we earned getting the first product used.

Before I build the next thing, I want to know who I can call about it.