How to cross-promote your own apps without spamming your users
You have shipped a few things. Each one has its own users, and none of those users know the others exist. This is about closing that gap in a way that is still true in two years, and that does not turn your product into a billboard for your other products.
By Utkarsh Kushwaha · Published
The line you are trying not to cross
Cross-promotion has a bad name because most of it is done badly: a modal on first load, an email blast to users who signed up for something else, a banner that occupies the top of the app. Those work in the sense that they generate clicks, and they cost you the thing that made the user like your product in the first place.
The distinction that matters is whether the promotion interrupts. A permanent, small, ignorable link is a fact about your product, in the same category as a footer or an about page. A modal is an interruption. The first one can sit there for five years and nobody minds. The second one buys you a spike and some resentment.
The corollary is that ignorable placements have to be permanent to be worth anything. A footer link that 0.5% of visitors click is only interesting because it does that every day, forever, on every page, for free.
The four ways, and what each costs
A hand-edited footer list. Add a 'my other projects' block to each site's footer. Zero dependencies, total control, and it is correct exactly until you ship the next thing. With n projects, every launch is n edits across n codebases, and the codebases are in different frameworks, deployed different ways, some of which you have not touched since last year. Realistically this decays after your second launch.
A links page you point everything at. One page listing everything, and each product's footer links to it. Now shipping something new is one edit. The catch is that it moves the decision one click away: the visitor has to want to leave your product before they see anything, so the click-through is a fraction of what an in-place list gets. Better than nothing, and cheap.
A shared component in a monorepo. If all your projects genuinely live in one repo with one build, a shared footer component is the clean answer. Most portfolios of side projects are not that: they are four repos, three frameworks, two of them not deployed from your machine any more.
An embedded widget that reads a hosted list. One line per site, the list lives in one place, and every site picks up changes without being touched or redeployed. This is the version that still works when the fourth project is a Webflow site and the second one is a Hugo blog you have not built locally since 2024.
The n-squared problem, concretely
It is worth doing the arithmetic once, because it is the thing that decides which of the four options above you will still be using in a year.
With three projects and a hand-edited footer, shipping a fourth means three edits. With five, shipping a sixth means five edits: five repos to clone, five builds to run, five deploys to check. The work of keeping the list correct grows with the square of the number of things you have shipped, which is precisely backwards: the more you ship, the more valuable the cross-linking becomes, and the less likely you are to maintain it.
Every approach where the list is duplicated per site has this shape. Every approach where the list lives in one place does not.
Where to put it so it gets seen but does not intrude
Bottom corner, on every page, small. Not the top. The top of the viewport is your product's, and anything you put there competes with your own interface. Not a single page. The person you want is deep inside the app, using it, not on the marketing homepage they saw once.
It should be legible about what it is. A visitor who cannot tell whether they are looking at an ad, a widget, or part of your product will treat it as an ad. A label with your own name on it, 'more from [you]', reads as a fact about the author, which is what it is.
And it must be able to do nothing gracefully. Anything embedded on every page of every site you own will eventually fail to load: a blocker, an outage, a bad network. If the failure mode is a broken box or a layout shift, you have made your products worse in exchange for a link. If the failure mode is that nothing renders at all, you have not.
What to measure
One number: clicks from each site, over time. Not impressions, which tell you what you already know, everybody who loads the page sees it. Not conversion, which you cannot attribute across four separate products without building tracking you should not build.
The useful signal is comparative. If site A sends thirty clicks a month and site B sends two, that is a fact about where your traffic actually is, and it is usually a surprise. It tells you which project to keep improving and which launch actually landed.
Questions people ask about this
Will linking my own sites to each other look like a link scheme?
No. A handful of related sites by the same author, linking to each other honestly and visibly, is ordinary web behaviour. Link schemes are large-scale networks built solely to pass ranking signal, usually with hidden or unrelated links. Four side projects with a shared footer are not that, and search engines have never treated them as such.
Should the cross-links be on every page or just the homepage?
Every page. Most of your real traffic never sees your homepage, it lands on a deep page from search or a shared link, does the thing it came for, and leaves. Homepage-only placement misses most of the audience you are trying to reach.
How many projects before this is worth setting up?
Two is where it starts working and three is where it compounds. With one there is nothing to point at.
Where Make Taksh fits
Make Taksh is one line of code you paste into each site you own. It renders a small badge in the corner that lists everything you have shipped, reading from one hosted list, so adding your next project is one edit and every site you have already installed it on picks it up within minutes. It is under 8 KB, renders in a shadow root so it cannot touch your CSS, sets no cookies, and draws nothing at all if it fails to load.