Solo Developer Workflow: AI Agents + SSH + One Terminal

If you're building a SaaS product alone in 2026, you're wearing at least five hats: frontend developer, backend engineer, DevOps specialist, documentation writer, and product manager. The traditional advice is to focus and outsource what you can't do well. But when you're bootstrapping, outsourcing means burning runway, and focus means shipping slower.

AI coding agents have fundamentally changed this equation. Not because they write perfect code (they don't), but because they collapse the context-switching cost between different parts of your stack. The question isn't whether to use them anymore. It's how to organize your workflow so you're not drowning in terminal tabs, SSH sessions, and half-finished agent conversations.

This post walks through a realistic daily workflow for shipping a full-stack SaaS product as a solo developer, using AI agents, SSH infrastructure management, and project-based terminal organization to operate like a small team.

The Solo Developer's Leverage Problem

Let's say you're building a B2B analytics platform. Your Tuesday might look like this:

• 8am: Fix a React rendering bug reported by a customer
• 10am: Optimize a PostgreSQL query that's timing out
• 12pm: Deploy the fix to production
• 2pm: SSH into your server to debug why background jobs aren't processing
• 4pm: Update API documentation
• 6pm: Write unit tests for the new feature you shipped Friday

That's six different contexts. Six different skill sets. Six opportunities to lose an hour just getting oriented.

The old solution was to batch similar work. Frontend Tuesdays, backend Thursdays. But that doesn't work when you have production fires or customer requests. You need to move fast across the entire stack.

AI Agents as Context Multipliers

Here's what changed in the last year: AI coding agents got good enough to handle the majority of implementation work across different domains, as long as you can clearly specify what you want.

I use two agents daily:

Claude Code (GPT-5.2 under the hood) for architectural decisions and complex refactoring. When I need to restructure my Next.js API routes or figure out why my Tailwind build is producing duplicate styles, Claude Code reads the entire codebase context and suggests changes that actually work.

Codex CLI (Gemini 3 based) for implementation and repetitive tasks. Writing migration scripts, generating TypeScript types from API responses, converting designs to React components. The kind of work that's straightforward but time-consuming.

The key is knowing which agent to reach for. Claude Code for "why is this happening and how should I fix it?" Codex for "write the code to make this happen."

A Day in the Life: Shipping a Feature End-to-End

Let me walk through yesterday. I needed to add export functionality to my analytics dashboard—let users download their data as CSV.

Morning: Planning and Implementation (9am-12pm)

I start a Claude Code session in my main project directory:

claude-code
> I need to add CSV export for the analytics dashboard.
> Users should be able to export filtered data.
> Walk me through the architecture.

Claude scans my codebase and suggests:

1. Add a new API route /api/analytics/export
2. Stream the CSV to avoid memory issues with large datasets
3. Reuse the existing filtering logic from the dashboard query

Good. That saves me from reinventing data fetching logic.

I switch to Codex to generate the implementation:

codex generate export-handler --spec "API route that streams
CSV data from PostgreSQL query results, using existing
analytics filters"

Codex gives me a working implementation in 30 seconds. I review it, make a few tweaks (it tried to load everything into memory first, which defeats the point), and commit.

Frontend time. Back to Claude Code:

> Add a download button to the analytics dashboard that
> calls the export endpoint and triggers a file download

Claude suggests using a client-side fetch with blob handling. It writes the React component, updates the dashboard layout, and even adds loading states. I test it locally—works on the first try.

Total time: 2 hours. Without agents, this would have been a half-day feature, minimum.

Afternoon: Deployment and Infrastructure (1pm-3pm)

Now I need to deploy this to production. My production server is a small VPS running Ubuntu. I SSH in to pull the latest changes:

ssh production
cd /var/www/analytics-app
git pull origin main
npm run build
pm2 restart analytics

While I'm in the SSH session, I check the Postgres slow query log. There's a query that's been running slower since I added the filtering logic last week. I open a local tunnel to access pgAdmin:

ssh -L 5433:localhost:5432 production

Now I can connect pgAdmin locally to port 5433 and it forwards to PostgreSQL on the production server. I run EXPLAIN ANALYZE on the slow query, realize I'm missing an index, and add it:

CREATE INDEX idx_analytics_user_created
ON analytics_events(user_id, created_at);

Query time drops from 4 seconds to 40ms. Small wins.

I also need to check application logs. Rather than tailing them in the SSH session, I set up a port forward to access my Grafana dashboard (running on port 3001 on the server):

ssh -L 8080:localhost:3001 production

Open localhost:8080 in my browser, and I'm looking at production metrics. No errors from the new export feature. Good.

Evening: Documentation and Tests (6pm-8pm)

I use Claude Code again to update the API documentation:

> Update the API docs in /docs/api.md to include the
> new export endpoint

It reads the code I wrote earlier, infers the parameters, and writes clear documentation with examples. I skim it, fix a typo, commit.

For tests, I switch back to Codex:

codex generate test --file src/app/api/analytics/export/route.ts

It generates Jest tests covering the happy path and edge cases (no data, invalid filters, large datasets). I run them, they pass, I commit.

Total evening time: 90 minutes. Writing docs and tests manually would have taken at least twice that.

Managing Remote Infrastructure as a Solo Developer

When you're running your own servers, SSH becomes your lifeline. But managing multiple hosts, port forwards, and file transfers gets messy fast.

Here's my setup:

SSH Config: I keep all my production and staging hosts in ~/.ssh/config:

Host production
  HostName 192.0.2.10
  User deploy
  IdentityFile ~/.ssh/id_production

Host staging
  HostName 192.0.2.20
  User deploy
  IdentityFile ~/.ssh/id_staging

Now I can just type ssh production instead of remembering IP addresses.

Port Forwarding: I use SSH tunnels constantly to access admin dashboards that shouldn't be exposed publicly. Postgres, Redis, Grafana, even the Next.js dev server when I'm testing something on staging.

The pattern is always:

ssh -L local_port:localhost:remote_port host

For example, to access staging's Redis instance:

ssh -L 6380:localhost:6379 staging

Now redis-cli -p 6380 on my laptop connects to staging Redis.

File Transfer: When I need to move files between my laptop and servers (config files, database backups, logs for local analysis), I use scp:

scp production:/var/log/app/errors.log ~/Downloads/

Or if I need to upload a new environment file:

scp .env.production production:/var/www/analytics-app/.env

All of this happens in terminal sessions that I keep organized by project.

Project Organization: One Terminal, Multiple Contexts

The biggest workflow killer is terminal chaos. Ten tabs open, three SSH sessions, and you can't remember which one is connected to production.

I organize everything by project using persistent terminal sessions (via tmux or zellij). Each project gets its own session with named windows:

analytics-app session:

• Window 1: local - local development, running npm run dev
• Window 2: agent - AI agent conversations (Claude Code or Codex)
• Window 3: ssh-prod - SSH connection to production server
• Window 4: ssh-staging - SSH connection to staging server
• Window 5: editor - quick file edits when I don't want to leave the terminal

When I need to work on analytics-app, I attach to that session. Everything is exactly where I left it. When I switch to my marketing site project, I attach to that session instead.

Sessions persist across terminal restarts, so even if I close everything and reboot, my contexts are intact.

The Toolchain: What Actually Matters

After six months of iterating on this workflow, here's what I can't live without:

1. AI Coding Agents: Claude Code for architecture and complex problems, Codex CLI for implementation and generation. Having both gives me the right tool for the job.

2. Persistent Terminal Sessions: Tmux or zellij. Non-negotiable. Losing your SSH session because you closed a terminal window is not acceptable in 2026.

3. SSH Management: A well-maintained ~/.ssh/config and muscle memory for port forwarding patterns. This is your remote infrastructure interface.

4. Project-Based Organization: One session per project, named windows for different contexts. Eliminates the "which terminal is this?" problem.

5. A Good Terminal: This should be obvious, but you need a terminal that handles splits, tabs, and session management well. The built-in Terminal.app is not that.

Why Agents UI Exists

I built this workflow over months of trial and error. The problem was that it required stitching together four different tools: a terminal emulator, a session manager, AI agent CLIs, and SSH configs scattered across dotfiles.

Agents UI is my attempt to collapse all of this into one native macOS app. Multi-session support with persistent state (powered by bundled zellij). First-class SSH workflows with file transfer UI and port forwarding management. A built-in Monaco editor so you don't need to leave the terminal for quick edits. And AI agent integration that works alongside your terminal, not in a separate window.

It's built specifically for solo developers and indie hackers running the workflow I described above: AI agents for leverage, SSH for infrastructure, and project-based organization to keep everything sane.

If you're shipping a SaaS product alone, you don't need a bigger team. You need better tools and tighter workflows. AI agents give you the leverage. SSH gives you control over your infrastructure. Persistent sessions give you context continuity. Put them together in one terminal, and you can operate like a team of three.

---

Agents UI is in private beta. Built with Tauri and Rust for native performance on macOS. If you're shipping solo and want early access, reach out on Twitter or email agents-ui@example.com.