How I Replaced a Team of 5 with Claude Code

I run SubraLabs, a software development company that builds iOS apps and web platforms, completely alone. No CTO, no project manager, no DevOps engineer, no finance person, no marketing team. Just me, Claude Code, and a set of systems I built on top of it.

This isn't a weekend project. SubraLabs has paying clients, shipped apps, tracked finances, managed email, audited security, and code pushed to GitHub every single day. Here's how the whole thing works.

The Session Lifecycle

Every working session follows a precise cycle. It starts the moment I open Claude Code.

A SessionStart hook fires automatically and runs a script that does two things: first, it syncs emails from Apple Mail into organized markdown files sorted by project. Second, it presents a summary with the latest status logs, unread emails, and priorities from the previous session.

At the end of a session, the /conclude skill handles cleanup: commit and push to GitHub, create or update the day's status log, set priorities for the next session, and rebuild the ops dashboard. Everything gets saved, everything gets pushed.

And a Stop hook prevents me from closing the session if there are uncommitted changes. No exceptions. Everything ends up on GitHub.

Skills: Reusable Workflows

I have 17 custom skills, each defined as a .md file in .claude/skills/. Every skill is a structured prompt with YAML frontmatter that Claude Code interprets and executes. They're not scripts. They're instructions.

The key ones:

/standup gives me a project overview at the start of a session. It reads PROJECT.md (the single source of truth), recent status logs, emails grouped by thread, and priorities. Outputs structured tables. This is my morning briefing.

/conclude handles session closure: commit, push, status log, priorities, dashboard rebuild. Described above.

/briefing is a quick morning snapshot with burn rate, priorities, and important emails. Faster than a full standup.

/finance-report generates a full financial report with trends and projections. It reads the synced JSON data, analyzes burn rate, and flags renewals and anomalies.

/review runs an automated code review before pushing, checking security, performance, and conventions.

/deploy-site and /deploy-testflight handle one-command deployments, so I never have to remember CLI flags or build steps.

/social and /marketing help with content generation and strategy planning.

/design generates visual assets like app icons, social graphics, and marketing materials.

Every reporting skill follows the same pipeline: read data, analyze, generate markdown report, save, rebuild the report index, commit and push. The consistency means I never have to think about where reports end up.

Agents: A Virtual C-Suite

I have 11 custom agents, each with a specific role and calibrated permissions. This is where it gets interesting, because the permissions are the real design decision.

Four C-suite agents handle management:

• COO handles daily operational reports, email triage, and coordination
• CFO handles financial analysis, burn rate tracking, and renewal alerts
• CSO handles security audits, dependency scanning, and secrets detection
• Analyst handles market research, competitor analysis, and app ideas

Seven dev agents handle technical work: code reviewer, debugger, tester, designer, marketer, social writer, and more.

The critical detail: permissions are granular. The C-suite agents are read-only, meaning they can analyze files and produce reports but cannot modify code. Only the debugger and tester can edit files. Only the analyst, designer, and marketer have web access.

This isn't paranoia. It's architecture. An agent that can both diagnose and fix is an agent that can break things. An agent that can only read and report is an agent you can trust to run unsupervised.

Every agent uses the Opus model, the most capable one. I never use cheaper models for agents. When an agent runs autonomously at 2 AM analyzing your client's email, you want it to be as smart as possible.

Hooks: Guardrails That Enforce Discipline

Four types of hooks create automatic guardrails around every session:

SessionStart provides auto-context by syncing email and presenting the daily summary. I never start a session without context.

PreToolUse fires on every Edit or Write operation. One rule: block any modification to financial files in finanze/ or .env files. This is a hard security boundary. No agent, no skill, and no accidental command can touch financial data or environment secrets.

PostToolUse runs SwiftLint automatically after every edit to a .swift file. Code style is enforced at the tool level, not at review time.

Stop blocks session closure if there are uncommitted changes. If I try to walk away with modified files, the hook says no.

These aren't suggestions. They're enforced. The hooks run whether I remember them or not, and that's the point.

The Company Runs While I Sleep

Five scheduled tasks run in the background via Cowork, Anthropic's desktop app for autonomous agents:

1. daily-report runs every day, covering what got done, project status, emails analyzed, and priorities for tomorrow
2. email-triage runs every day with point-by-point email analysis, urgency classification, and draft responses
3. market-analysis runs weekly to find potential clients, analyze competitors, and generate app ideas
4. finance-report runs weekly covering burn rate, trends, projections, and renewal alerts
5. security-scan runs twice a month with dependency audits, secrets scanning, and file permission checks

Each task produces a markdown report visible in the ops dashboard. The dashboard has 7 pages: Dashboard (KPIs, trends, tasks), Reports (filterable by category), Finances, Projects, Vault, and AI Chat. The AI Chat page lets me ask questions about the company's data and get contextual answers about projects, finances, and emails.

Memory: Cross-Session Coherence

I wrote a dedicated post about this, but the short version: 21 memory files organized into 4 types covering user profile, feedback (corrections and confirmations), project state, and external references.

These files give Claude Code continuity between sessions. It remembers my preferences, past mistakes, project status, and client contacts. Without memory, every session would start from scratch, like hiring a new contractor every morning.

The memory system isn't a database. It's a handful of .md files with YAML frontmatter. Simple, grep-able, version-controllable.

What This Actually Costs

The entire infrastructure runs on one subscription: Claude Max. That covers Claude Code, Cowork for scheduled tasks, and all the AI features in the ops dashboard.

No additional SaaS. No server costs. No team salaries. The ops dashboard runs locally on my machine. The email sync reads from Apple Mail. The financial data lives in an Excel spreadsheet.

Is this setup perfect? No. It doesn't replace a real team for a 50-person startup. It can't handle the ambiguity of a board meeting or the nuance of a difficult client call. Those things still need a human, specifically me.

But for a solo founder building apps for clients? It works. SubraLabs has its first paying client, apps in active development, finances tracked to the cent, email triaged daily, security audited bi-monthly, and every line of code pushed to GitHub before I close the laptop.

The org chart is just me and a fleet of AI agents. And honestly, the agents are more reliable than most interns I've heard about.