Make your own apps sell each other: the cross-promo strip

If you ship more than one product, you have a silo problem, and it's almost certainly worse than you think.

Ours looked like this: nine apps, most with their own subdomain, each with its own visitors. Someone lands on the Slate site, likes it, installs it, leaves. They will never learn that the same studio makes a notch app, a link queue and a Chrome extension. Every product was starting distribution from zero, every single time, while sitting on traffic that had already decided it liked our work.

The fix is a cross-promo strip: a small, consistent band on every one of your properties that shows the rest of the catalogue. It is the cheapest distribution channel you will ever own, and it takes an afternoon.

Why it works better than it should

The visitor has already passed the hard filter. They found you, read a page, and formed a positive opinion about your taste. That's the expensive part of marketing, and you've already paid for it.

Showing them three more things you've made costs nothing and converts unusually well, because it's not an ad, it's an answer to a question they've just started asking, which is "who made this?"

The design rules

Bottom of the page, not the top. The strip must never compete with the product the visitor came for. Above the fold it's an interruption; at the bottom it's a reward for someone who read to the end.

Show three or four, not nine. A wall of nine icons reads as a portfolio and gets skipped. Three reads as a recommendation. Rotate deterministically (by page, by product family, by whatever's most relevant to where the visitor is) rather than randomly, so it doesn't flicker between page loads.

Exclude the current product. Obvious, and the single most common bug in a strip like this.

Say what each thing is. An icon and a name means nothing to someone who has never heard of it. Eight words of what it does converts several times better than a logo grid.

Match the host site's chrome, not your studio brand. The strip should feel like a footer that belongs to the page it's on, not an injected banner. If it looks like an ad network, it gets tuned out like one.

One link out per item, no dark patterns. No interstitials, no "you may also like" modals, no exit-intent popups. You're not trying to trap this visitor; you're trying to be remembered.

The technical shape

Two decisions matter, and they're both about avoiding future maintenance.

One manifest is the source of truth. Every product (name, one-liner, icon, platforms, links, status) lives in a single file. The strip reads from it, and so does everything else: your store grid, your homepage, your OG images, your sitemap, your API. Adding a product becomes a one-file edit rather than a nine-site deploy.

Ours is a single products.ts. If you take one thing from this piece, take this one, it's the difference between a strip you maintain and a strip that quietly goes stale and starts advertising an app you sunset last year.

Ship it in two builds. This is the part people skip and then regret. Your sites are almost certainly not all the same stack: some are React, some are a static HTML file someone wrote in 2022, one is a landing page in a framework you no longer use.

So build the strip twice from the same manifest:

1. A component for the modern sites, imported directly.
2. A standalone script embed, one <script> tag that injects the markup, for everything else.

A React-only strip reaches half your properties, which is the same as not shipping it. The script build is maybe forty lines and it's what gets you the other half.

Keep it cheap. No framework, no external fonts, no layout shift. It's the last thing on the page; it must not cost anything to have there. Inline the icons or serve them from a domain you control, and give the container a fixed height so the page doesn't jump when it appears.

Measuring it without building a tracking apparatus

You want two numbers: how many people see it, and how many click through.

Resist the urge to add an analytics vendor for this. A click-through with a source parameter (?from=slate), counted server-side, tells you everything actionable (which host sites send traffic, and which products receive it) without a cookie, a consent banner or a third-party script on nine sites.

The number to watch after a month is per-host: some products send meaningfully more curious visitors than others, and it's rarely the ones with the most traffic. Adjust which products the strip favours accordingly.

When it doesn't work

When the products have nothing to do with each other. A menu-bar utility and a mobile game share a maker, not an audience. Cross-promo between them converts near zero. Group by audience, not by ownership.

When the host product is bad. A strip amplifies an opinion the visitor already has. If they're on the page because something is broken, showing them four more of your apps makes things worse.

When you have two products. The overhead of a manifest and two builds isn't worth it. Put a line in the footer and move on.

What it looks like here

You're on the studio site, so the store page is the maximal version of the idea, the whole catalogue, with an honest status on the unfinished ones. The strip is the compressed version of that, running on the individual product sites where the traffic actually is.

That's the real insight, and it's slightly deflating: the strip isn't clever. It's just that most multi-product makers never build it, and spend money on acquisition instead of connecting the audiences they already have.