Managing a Solo SaaS Portfolio

This approach is for the solo operator who has moved beyond simple automation into managing active, revenue-generating production environments. It requires a baseline understanding of DevOps and database management. It is not for hobbyists or those building static sites. The goal is to minimize the time spent writing code while maximizing the safety of the deployment pipeline.

What are the operational costs and time requirements?

Running this model involves three distinct cost layers. These are reported ranges based on my experience managing a portfolio of roughly 40 domains and several active SaaS products.

• Cash Cost (Infrastructure & Intelligence): $150 – $500 per month. This covers high-tier LLM subscriptions (Claude 3.5 Sonnet/GPT-4o), VPS hosting (Hetzner, DigitalOcean, or AWS), and database managed services. The primary cost is the "intelligence tax"—paying for the highest-reasoning models to ensure the agent's PROPOSED.md files are accurate.
• Time Cost (The Audit): 1–3 hours per significant feature or fix. While the agent writes the code in minutes, the human's job is the audit. You must read the proposal, verify the rollback steps, and check the blast radius. If you spend less time here, you are gambling with your uptime.
• Risk Cost (The Failure Variable): Variable. The cost of a failed deployment can range from a 15-minute outage to a total loss of data if a database migration is mishandled.

How do you implement an Agent-First deployment workflow?

The core principle is that every change to production starts as a file, not a command. You must strip the agent of its ability to execute shell commands that affect the live environment without a multi-stage verification process.

• The Change: A precise list of every file, database table, and environment variable that will be touched.
• Blast Radius: A logical assessment of what else might break (e.g., "Changing the User schema will affect the Auth service and the Billing webhook").
• Rollback Plan: The exact, manual commands required to revert the change if the "Checks" fail. This must be written before the change is applied.
• Verification Checks: A list of specific indicators (logs, UI elements, or database row counts) that prove the change worked.

Step 3: Restricted Execution
You must manually revoke the agent's ability to run high-risk commands. In a typical Solo SaaS setup, the following commands should be strictly off-limits to the agent unless you are actively watching the terminal:

• npm run build (In many setups, building the frontend directly on the server serves the new files to users immediately. A "quick build" is a deployment.)
• pm2 restart or any process manager restarts.
• nginx -s reload or any web server configuration changes.
• git push (If your CI/CD is set to auto-deploy on push, the agent effectively has a direct line to your customers.)

How do you handle database migrations safely?

Database drift is the most common way AI agents destroy production environments. Tools like Prisma are excellent for development, but they can be dangerous when used by an agent on a live server.

The "Prisma Trap"
Never allow an agent to run prisma migrate dev on a production server. This command is designed for local development; if it detects a discrepancy between your schema and the database, its default behavior might be to reset the database to sync it. On a local machine, this is a minor inconvenience. On a production SaaS, it is a business-ending event.

Similarly, avoid prisma db push. This command bypasses the migration history entirely. If an agent uses it to "fix" a schema error, you lose the audit trail of your database evolution, making future rollbacks impossible.

The Safe Sequence
The only way to manage schema changes is through a rigid, manual sequence. Before any migration, the agent must facilitate a backup:

1. Generate a backup: pg_dump -Fc mydb > /backups/pre_migration_$(date +%F).dump
2. Verify the backup file size and integrity.
3. Apply migrations using a strictly controlled prisma migrate deploy command, which only applies pending migrations and never resets the database.

Where does this method fail?

I hit a major wall when I tried to automate the "Verification" phase. I thought, "If the agent writes the checks, let the agent run the checks."

This failed because of Confirmation Bias in LLMs. If an agent writes a test that checks if a new feature is working, and then that same agent runs the test, it will often hallucinate a "Pass" because its internal logic is consistent with the flawed code it just wrote. It will see what it expects to see.

Comparison: Agent-Driven vs. Traditional DevOps

This method is not "Automated DevOps." It is "Human-in-the-loop Orchestration." Here is how it differs from the standard industry approaches:

• vs. Traditional CI/CD (GitHub Actions/GitLab CI):
  Traditional CI/CD is reactive and triggered by code pushes. My method is proactive and triggered by a PROPOSED.md file. In traditional DevOps, the "gate" is a suite of automated tests. In this method, the "gate" is a human reading a logic document. Use traditional CI/CD for large teams; use this for solo operators who need to move fast without a DevOps engineer.
• vs. Fully Autonomous AI Agents (AutoGPT/BabyAGI):
  Fully autonomous agents attempt to complete a goal without intervention. This is suicidal for production SaaS. They lack the "context of consequence." The Agent-Driven method uses the agent as a highly skilled junior developer who must submit a written report for every single action.
• vs. Manual Coding:
  Manual coding is safer but lacks scale. You cannot manage 42 domains and a fleet of assistants by typing every line of CSS and SQL. The Agent-Driven method trades a small increase in risk for a massive increase in operational capacity.