How I Keep 3 Live Apps Running From One Laptop (Solo Ops

By Lazar Milicevic · Published June 16, 2026 · 10 min read

You shipped product one. It pays. You started product two because solo math demands it. Then a client asked for a custom internal tool, and now you're three codebases deep with a Telegram alert at 7am saying invoicing is down in a timezone you don't live in. Building isn't the problem anymore. Keeping things alive is.

Most Claude Code content stops at launch day. This is the part nobody films: the ops stack I actually run from one laptop, with six Claude Code sessions open at the same time, shipping client automations for a living without taking down a paying customer while I sleep.

One machine, one OS, one source of truth

The first instinct when you scale to multiple apps is to scatter your dev environment. Cloud dev box for app A, Codespaces for the client tool, a remote VPS for "experiments." Don't.

When you switch between three codebases twenty times a day, latency is the silent killer. Every SSH hop, every cold container, every "wait for the cloud IDE to wake up" is friction that compounds across a hundred context switches. I run a mid-spec desktop — the kind of box you'd build for gaming — with WSL Ubuntu on Windows. That's the whole development environment.

The only things that live in the cloud are the deployed apps and the production databases. Everything else — code, git, dependencies, Claude sessions, logs — is local.

Minimum viable hardware for a 3-app solo stack

• 32 GB RAM (16 GB works but you'll feel it once three Claude sessions, Docker, and a browser are open)
• A CPU with 8+ cores so tmux panes don't fight each other
• An SSD large enough that you never think about disk space mid-context-switch
• WSL Ubuntu if you're on Windows; native Linux or macOS otherwise — pick one and stop distro-hopping

The point isn't the spec sheet. It's that one keyboard shortcut gets you from any codebase to any other. Not three SSH hops. Not a browser tab. One shortcut.

The six-pane tmux layout (no more, no less)

Most people get tmux wrong by trying to be clever. They build elaborate session managers, custom layouts per project, status bars with weather widgets. I use six panes. That's the whole thing.

┌──────────────────┬──────────────────┬──────────────────┐
│  Pane 1          │  Pane 2          │  Pane 3          │
│  Claude: App A   │  Claude: App B   │  Claude: Client  │
│  (Fakturko)      │  (UNA_Intel)     │  tool            │
├──────────────────┴──────────────────┴──────────────────┤
│  Pane 4: logs tail (whichever app I'm touching now)    │
├────────────────────────────┬────────────────────────────┤
│  Pane 5: deploy + git      │  Pane 6: scratch shell     │
│  (human-driven only)       │  (curl, psql, one-offs)    │
└────────────────────────────┴────────────────────────────┘

Three Claude Code sessions, one per app, each pinned to that app's directory. Pane 4 is a logs tail for whichever app is hot that hour. Pane 5 is a plain shell where I run commits, pushes, and deploy commands by hand. Pane 6 is a scratch pane for one-off queries.

That's it. No seventh pane. When something new comes up, it goes into pane 6 and gets closed when I'm done. The discipline is more important than the tooling.

Here's the bootstrap script I run once at the start of the day:

#!/usr/bin/env bash
# ~/bin/ops-start
SESSION="ops"

tmux new-session -d -s $SESSION -n main
tmux send-keys -t $SESSION "cd ~/code/fakturko && claude" C-m

tmux split-window -h -t $SESSION
tmux send-keys -t $SESSION "cd ~/code/una_intel && claude" C-m

tmux split-window -h -t $SESSION
tmux send-keys -t $SESSION "cd ~/code/client-tool && claude" C-m

tmux select-layout -t $SESSION even-horizontal

# Bottom row
tmux split-window -v -t $SESSION.0 -p 40
tmux send-keys -t $SESSION "cd ~/code/fakturko && tail -f logs/app.log" C-m

tmux split-window -h -t $SESSION
tmux send-keys -t $SESSION "cd ~/code" C-m  # deploy/git pane

tmux split-window -h -t $SESSION
tmux send-keys -t $SESSION "cd ~ " C-m       # scratch

tmux attach -t $SESSION

One command. Six panes. Same layout every morning.

Per-project CLAUDE.md, hand-written, no shared template

This is the step nobody talks about, and it's the one that stops Claude from making decisions in app A based on conventions that only exist in app B.

Each app has its own CLAUDE.md at the root of the repo. The files do not share content. I used to keep a master template I copied between projects. Within a week the files drifted, and Claude started suggesting a Postgres pattern in the SQLite app because that's what the template said.

Each file is hand-written, under 200 lines, and contains:

• The stack (concrete versions, not "Node-ish")
• The deploy target (Fly, Hetzner box, Railway — whatever it actually is)
• The database schema in plain English (not the SQL — Claude can read the SQL)
• The 3-4 non-obvious conventions for this codebase
• A list of files Claude must never touch without asking — migration scripts, billing logic, anything that can corrupt customer data

Here's a real shape:

# CLAUDE.md — Fakturko

## Stack
- Python 3.11, FastAPI 0.110, SQLAlchemy 2.0
- Postgres 15 on Hetzner CX22
- Deployed via `make deploy` (rsync + systemd restart)

## Domain
Serbian small-business invoicing. Invoices are immutable once issued —
never UPDATE a row in `invoices`, only INSERT a new version with
`replaces_id`. The tax authority audits this.

## Conventions
- All money is `Decimal`, never `float`. Stored as integer cents in DB.
- Dates use Europe/Belgrade. Never assume UTC at the API boundary.
- Customer emails go through `services/mailer.py` only — it handles
  the SPF/DKIM domain rotation.

## Do not touch without asking
- `alembic/versions/*` — migrations are reviewed by hand
- `services/billing.py` — has audit-trail logic
- `services/tax_calc.py` — Serbian tax rules, do not "simplify"

If your CLAUDE.md is longer than 200 lines, you're documenting things Claude can read from the codebase itself. Keep it tight, keep it specific, keep it current.

The daily loop: one feed in, one app at a time

Without a loop you're just reacting to whatever pings loudest. The Telegram notification beats the calendar, the customer email beats the Telegram, and by 11am you've touched three repos and finished nothing.

My day has a fixed shape:

The ops bot is the keystone. It runs on the same server, polls each app's health endpoint, watches webhook failures, and forwards any customer email flagged urgent. One feed, triaged in ten minutes. I never open three dashboards in the morning.

The build block is the rule that took me longest to enforce: one app at a time. The other Claude sessions sit idle. If app B isn't on fire, app B doesn't get touched until app A's task is shipped. Parallel building across three codebases sounds productive and produces bugs in all three.

Three guardrails that stop one bad deploy from killing a customer

At this scale, a bad deploy is the difference between a quiet evening and an emergency hotfix at midnight for a customer in a timezone where it's already morning. Three rules, no exceptions.

The non-negotiables

• No Claude session runs a deploy command directly. Claude can write the deploy script. Claude can explain exactly what will happen. The human types the actual command in pane 5. Every time.
• Every app has a staging environment that's one git push away. Nothing reaches production without going through staging first, even a one-line typo fix. Especially a one-line typo fix — those are the ones that take prod down.
• A 30-second changelog in each repo, written by me, not generated. Plain text. Date and what changed. When something breaks two weeks later, that file tells me what to look at first.

The changelog looks embarrassingly low-tech:

# CHANGELOG.txt
2024-11-18  Switched mailer to backup SMTP. Primary rate-limiting us.
2024-11-15  Added replaces_id index on invoices. Search was 4s+.
2024-11-12  Webhook retry now exponential, was fixed 30s.
2024-11-08  Fixed VAT rounding for items priced under 100 RSD.

That's it. Ten seconds to write, saves hours when you're debugging an issue that started "sometime last week."

A note on staging: it doesn't have to be fancy. For two of my three apps, staging is a second systemd service on the same Hetzner box, pointed at a separate database, behind a basic auth nginx block. Costs nothing extra. The point isn't infra purity — the point is that the deploy path has been exercised before it hits a paying customer.

Why bizflowai.io helps with this

The ops bot, the health checks, the Telegram triage layer — that's exactly the kind of glue I build for clients through bizflowai.io. Most small teams I work with don't need another dashboard; they need a single feed that surfaces what actually requires a decision today, wired into the tools they already use. The patterns in this post (per-project context isolation, human-in-the-loop deploys, a one-feed morning triage) are the same patterns I deploy into client stacks so a two-person team can run what would normally take five.

The shape of it

Three apps from one laptop isn't about a clever tool. It's about removing decisions from the day:

• One machine, so context-switching costs zero seconds
• Six tmux panes, so you always know where every session lives
• One CLAUDE.md per repo, hand-written, so Claude never confuses your apps
• One daily loop, so the right fire surfaces at the right time
• Three guardrails, so a tired evening deploy doesn't take down a paying customer

None of it is exciting. That's the point. The boring infra is what lets you stay solo while running things that real customers depend on. Build that layer once, properly, and product number three stops feeling like the one that breaks you.

Frequently asked questions

What is the operational wall solo builders hit at three products?

It's the point where running existing products consumes more time than building new ones. With three live codebases, a solo builder faces silent webhook failures, cross-timezone alerts, and context-switching chaos. The problem isn't building speed but orchestration, context isolation, and a daily loop that surfaces the right issue at the right time. Most one-person shops cap at one product because they never build this ops layer.

How do I set up a tmux layout for managing multiple codebases with Claude Code?

Use exactly six panes. Three panes run Claude Code sessions, one per app, each pinned to that app's directory. Pane four tails logs for whichever app you're touching. Pane five is a plain shell for git commits, pushes, and manual deploys, keeping a human in the loop for production. Pane six is a scratch pane for one-off queries like database checks or curl tests. Never open a seventh pane.

Why should each project have its own CLAUDE.md file instead of a shared template?

Shared templates drift within a week, causing Claude to apply conventions from one app to another and make wrong decisions. Each CLAUDE.md should be hand-written for that specific app, containing the stack, deploy target, database schema in plain English, three or four non-obvious conventions, and a list of files Claude shouldn't touch without asking, like migrations and billing logic. Keep it under 200 lines.

When should I use a local dev environment vs cloud development tools?

Use local when you're switching between multiple codebases many times a day, because latency kills productivity. A single mid-spec desktop running WSL Ubuntu on Windows, or a laptop with 32GB RAM, handles it. Keep local file system, local git, and local everything. Only deployed apps and databases should live in the cloud. Avoid Codespaces, remote VPS dev boxes, or SSH-based workflows for active development.

How do I avoid reactive chaos when running multiple products solo?

Build a daily loop centered on one notification surface instead of monitoring multiple dashboards. Use a custom ops bot, for example a Telegram chat, that surfaces overnight breakages, decisions needed, and urgent customer emails in one place. Run the bot on the same server as your apps. This replaces opening three SaaS dashboards each morning and ensures you respond to the loudest fire deliberately, not whichever ping arrives first.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.