6 Tools Run My 3 Live AI Products Solo (Deleted 14)

By Lazar Milicevic · Published June 25, 2026 · 9 min read

I deleted 14 tools from my one-person AI business stack last year. The six that survived run three live products for paying customers, on a quiet PC in the corner of a room. Most tutorials show you the setup. Almost nobody shows what stays after real users hit it for 18 months.

If you've watched a four-hour Claude Code course and ended up with twenty browser tabs, an n8n instance, a Supabase project, and a Vercel bill, you already know the shape of the problem. By Friday you have a stack that costs $380/month and runs nothing for nobody. I lived that. Here's what's left after I cut everything that wasn't pulling its weight.

Tool 1: Claude Code as orchestrator, not autocomplete

Claude Code is the first tool in the stack, but not the way most tutorials use it. In production, it's not a fancy autocomplete inside VS Code — it's the orchestrator that owns every product folder. Each product gets one file at the root called CLAUDE.md, and that file is the project's context: what it does, where the database lives, which scripts deploy it, what the cron schedule looks like, which commands are dangerous.

When I cd into a product folder and run claude, it boots into full context in about 90 seconds. I don't paste files. I don't re-explain the project.

A real CLAUDE.md from one of my products looks like this:

# Fakturko — Invoice automation SaaS

## What this does
B2B invoicing tool. Users upload bank statements,
we match payments to outstanding invoices, send reminders.

## Stack
- Postgres schema: `fakturko` on localhost:5432
- Runtime: Python 3.12, systemd service `fakturko.service`
- Cron: `/etc/cron.d/fakturko` (reminder sweep at 08:00 UTC daily)
- Deploy: `./deploy.sh` (pulls main, migrates, restarts service)

## Dangerous commands — ASK BEFORE RUNNING
- Any `DROP`, `TRUNCATE`, or `DELETE` without WHERE
- `systemctl stop fakturko` during business hours (07:00–19:00 UTC)
- Anything that touches `users` or `invoices` tables without a backup

## Where things live
- API: `src/api/` (FastAPI)
- Workers: `src/workers/` (long-running, managed by systemd)
- Schedulers: `src/jobs/` (called by cron)

That file is the leverage. Everything downstream — the schema work, the deploy script, the bug fixes — happens because Claude already knows the rules of the house.

Tool 2: WSL Ubuntu on a $400 home server

Tool two is WSL Ubuntu running on a small PC I built for around $400. People assume a one-person AI business has to be cloud-native. For three products with a few hundred users each, it doesn't. A quiet box in the corner of the room beats every cloud provider I tried on cost, latency, and sanity.

Real numbers from 18 months running it:

No cold starts. No surprise bills when a scraper loops. No dashboards to babysit. Claude Code runs on the server over SSH from my laptop, and when the laptop is closed the server keeps working. The one thing you trade is uptime guarantees — so I run a UPS, and I'm honest with customers that planned maintenance is a thing.

If you've never tried this, the setup is genuinely 30 minutes: enable WSL2, install Ubuntu, open SSH from your LAN, port-forward 443 on the router, point a domain at your home IP, and put Caddy in front for automatic TLS.

Tool 3: One Postgres, three schemas

Tool three is one Postgres instance with three schemas. Not three databases. Not three Supabase projects. One Postgres, one connection pool, three schemas — one per product.

CREATE SCHEMA fakturko;
CREATE SCHEMA una_intel;
CREATE SCHEMA bizflowai.io;

-- shared auth lives in `public`
CREATE TABLE public.users (
  id uuid PRIMARY KEY,
  email text UNIQUE NOT NULL,
  created_at timestamptz DEFAULT now()
);

-- per-product tables reference it
CREATE TABLE fakturko.invoices (
  id uuid PRIMARY KEY,
  user_id uuid REFERENCES public.users(id),
  amount_cents bigint,
  status text
);

The payoff shows up the day a customer asks "how many of my users are also on your other product?" That's one JOIN instead of stitching three REST APIs together. Cross-product reporting is a single query. Backups are a single pg_dump. Migrations run in one transaction.

Postgres is roughly 40 years old. It will outlive every AI tool in this post. I deleted Supabase because Postgres on my own server does the same job without the lock-in, and I deleted the vector DB because pgvector is a one-line extension.

What I gave up

• Row-level security configured through a UI (I write it in SQL now)
• Realtime websockets out of the box (I use Postgres LISTEN/NOTIFY instead)
• Managed daily backups (I run pg_dump to a second disk on cron, plus weekly to S3)

Tool 4: A Telegram bot instead of an admin panel

Tool four surprises people. I don't have an admin panel. I don't have a dashboard. I have one Telegram bot that wraps all three products' schemas, and I talk to it.

Some real commands I use daily:

/invoices_this_week acme-corp
/disable_user user@example.com
/failed_payments today
/db fakturko "SELECT count(*) FROM invoices WHERE status='overdue'"
/restart bizflowai.io

When a payment fails, the bot tells me. When a systemd service crashes, the bot tells me. When the nightly backup finishes, the bot tells me. Building three admin UIs would have taken weeks. Building one Telegram bot that wraps three database schemas took an afternoon with Claude Code, and the whole thing is about 600 lines of Python.

The conceptual point: a CLI you can use from your phone is a dashboard. It just doesn't have a frontend you have to maintain.

Tool 5: cron and systemd — no workflow builder

Tool five is cron and systemd. That's it. No n8n. No Zapier. No Make. No workflow builder.

Every automation in every product is either a systemd service that runs continuously, or a cron job that fires on a schedule. Claude Code wrote every one of these. When something needs to change, I open the folder, tell Claude what I want, it edits the unit file, and systemd reloads.

A real worker unit, end to end:

# /etc/systemd/system/fakturko-worker.service
[Unit]
Description=Fakturko payment matcher
After=network.target postgresql.service

[Service]
Type=simple
User=lazar
WorkingDirectory=/home/lazar/products/fakturko
EnvironmentFile=/home/lazar/products/fakturko/.env
ExecStart=/home/lazar/products/fakturko/.venv/bin/python -m src.workers.matcher
Restart=always
RestartSec=5
StandardOutput=append:/var/log/fakturko/worker.log
StandardError=append:/var/log/fakturko/worker.err

[Install]
WantedBy=multi-user.target

And a cron line:

# /etc/cron.d/fakturko
0 8 * * * lazar /home/lazar/products/fakturko/.venv/bin/python -m src.jobs.reminders

That's the whole automation layer for a product doing real revenue. Workflow builders look powerful in demos. In production, they become the thing you're afraid to touch because nobody — not even you — remembers exactly which node feeds which webhook. Plain cron and systemd never become that. They are boring. Boring is what you want at 2am.

I deleted n8n because every workflow I built in it eventually got rewritten in Python anyway. I deleted Make for the same reason. I deleted four different MCP servers because the value they added was less than the maintenance they cost.

Tool 6: git + one 40-line deploy script

Tool six is git plus one deploy.sh Claude wrote once, around 40 lines of bash. It pulls the latest code, runs migrations, restarts the systemd service, and posts to the Telegram bot when it's done. That is the entire CI/CD.

#!/usr/bin/env bash
set -euo pipefail

PRODUCT="$(basename "$PWD")"
SERVICE="${PRODUCT}.service"
TG_TOKEN="${TG_BOT_TOKEN:?}"
TG_CHAT="${TG_OPS_CHAT:?}"

notify() {
  curl -s -X POST "https://api.telegram.org/bot${TG_TOKEN}/sendMessage" \
    -d chat_id="${TG_CHAT}" -d text="$1" >/dev/null
}

notify "🚀 Deploying ${PRODUCT}..."

git fetch --quiet origin main
BEFORE=$(git rev-parse HEAD)
git reset --hard origin/main
AFTER=$(git rev-parse HEAD)

./.venv/bin/pip install -q -r requirements.txt
./.venv/bin/alembic upgrade head

sudo systemctl restart "${SERVICE}"
sleep 3

if systemctl is-active --quiet "${SERVICE}"; then
  notify "✅ ${PRODUCT} live: ${BEFORE:0:7} → ${AFTER:0:7}"
else
  notify "❌ ${PRODUCT} FAILED to start. Rolling back."
  git reset --hard "${BEFORE}"
  sudo systemctl restart "${SERVICE}"
  exit 1
fi

No GitHub Actions. No Docker. No Kubernetes. Forty lines. Total deploy time from git push to "live" message: about 12 seconds.

The deleted list (and the principle behind it)

This is the part nobody shows. The 14 tools I removed:

The principle is simple: if a tool can be replaced by 20 lines of code Claude writes in one prompt, the tool is the liability. The code is the asset. Tools have pricing pages, breaking changes, status pages, support tickets. Code you own has none of that.

This isn't an argument against SaaS in general. It's an argument against SaaS as the default. For a one-person business, every vendor you add is another thing that can wake you up at night.

Why this matters for marginal product cost

The reason the stack is interesting isn't that it's cheap. It's that the marginal cost of product number four is close to zero. When I onboard a new client product:

1. Create a folder, write a CLAUDE.md.
2. Run claude inside it.
3. Tell it: scaffold the schema, write the systemd service, write the cron jobs, write deploy.sh.
4. About 30 minutes later there's a running product on the same Postgres, the same Telegram bot, the same server, the same deploy pipeline.

No new vendor signups. No new monthly bills. No new dashboards. The same 6 tools just absorb another product.

That's the actual leverage of an AI-first solo stack in 2026: not that AI writes your code faster, but that AI-written code is so cheap to produce and replace that vendor tools stop making sense for the small stuff. The economics flip.

How this looks at bizflowai.io

The 6-tool pattern is what I install for clients running automation through bizflowai.io. The product handles the same shape of work — orchestrator file per workflow, one shared Postgres, plain schedulers, Telegram or email as the ops surface — so SMB owners get the reliability of an owned stack without having to learn systemd and SQL themselves. If you're already on n8n or Make and the bill is creeping up while the workflows feel fragile, that's usually the moment this pattern pays for itself.

Related reading

• 6 Files Boot Claude Into 3 Live SaaS in 90 Seconds — the CLAUDE.md pattern in detail.
• The 3-Agent Loop That Runs My Solo Agency (No Team) — what sits on top of this stack.
• Token Sprawl Is Real. Here's How to Cap It. — keeping the Claude Code bill sane.

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.