Running Several Side Projects From One Dashboard

Many indie hackers end up running more than one product. One app pays the bills, two are growing slowly, and a new one launched last month. Each started with a quick setup: an analytics account, a chat widget, a feedback board, a Stripe dashboard. Two years later, you have a dozen logins and no clear picture of which project deserves your next week.

This guide is about keeping a portfolio of small apps manageable: what to share between projects, what to look at every week, and how to decide where to spend your time.

The hidden cost of one tool per app

Every tool you add to a project has a cost beyond its price:

• Setup time for each new launch.
• Context switching every time you check five dashboards to answer “how is everything doing?”.
• Missed messages when a user writes in a widget you forgot was installed.
• Per-app pricing that adds up fast when every product is small.

When you run one app, none of this matters. When you run five, it becomes the work.

Share the boring parts

The parts of a product that users never see are the best candidates for sharing across projects:

• Authentication and billing code. Start new apps from the same template so login, checkout and emails already work.
• Hosting. One server or one platform account for all your apps, with the same deploy process.
• Analytics, support and revenue tracking. One tool across every project, so a new launch is one script tag instead of an afternoon of signups.

The goal is that launching a new app costs a weekend of product work, not a week of plumbing.

One inbox for every user conversation

User messages are the most valuable signal a small product gets, and the easiest to lose. If each app has its own chat tool, you will eventually miss a message from a paying customer.

Route every conversation into one inbox: support chats, feedback, bug reports, from every project. Filter by project when you want to focus, and keep a status on each thread (open, pending, closed) so you know what is still waiting on you. If you are offline when someone writes, make sure the reply can still reach them by email.

One dashboard for the numbers

For each project, you need a handful of numbers on one screen:

• Live visitors and pageviews, to see whether anything is happening right now and how traffic trends over 30 days.
• Open conversations, to see where users are waiting.
• MRR, to see which projects are actually paying.

Side by side, these answer questions that separate dashboards never do. A project with growing traffic and flat MRR has a conversion problem. A project with steady MRR and no traffic is living on past work. A project with lots of bug reports and growing MRR is worth fixing first.

A weekly review that takes 20 minutes

Once a week, go through every project with the same questions:

1. Traffic: up, flat or down compared to last week? Which source changed?
2. Users: what did people ask for or complain about? Is any question repeating?
3. Revenue: what changed in MRR, and was it new customers, upgrades, downgrades or churn?
4. One action: what is the single most useful thing to do for this project next week?

Write the answers down. After a month, patterns show up: the project that keeps growing without attention, and the one that keeps needing attention without growing.

Deciding where to spend your week

With the numbers in one place, a few simple rules help:

• Fix what paying users report first. Churn is easier to prevent than new MRR is to win.
• Double down where traffic converts. If a project turns visitors into trials, more traffic is the lever.
• Give quiet projects a deadline. If an app has had no traffic growth and no revenue for months, decide whether to market it, rework it or let it run on autopilot.
• Keep launches cheap. A shared template and shared tools let you test a new idea without adding another month of overhead.

Keep the overhead flat as you grow

The point of a portfolio is that each new app adds upside without adding much work. That only holds if the tooling stays the same size whether you run two projects or ten: one script, one inbox, one dashboard, one bill.

Run all your apps from one place

Indiehacker Studio was built for exactly this: paste one script tag on every app you run and get cookieless analytics, a support chat bubble, feedback, bug reports and Stripe revenue, all in one dashboard and one inbox. Start free with your first project.