A solo developer's journey from chaos to a fully tracked, evidence-based operation — powered by AI agents and 55 lines of Rust.
When you run a one-person company, you are not just the developer. You are the product manager, the QA team, the security auditor, the DevOps engineer, and the person who writes the closeout reports at 2 AM.
I tried everything: Notion for planning, GitHub Issues for tracking, spreadsheets for status, and a dozen AI chat windows for “assistance.” The result? Context scattered across 10 tools, no single source of truth, and a growing suspicion that I was spending more time managing my systems than building products.
The breaking point came when I realized I could not answer a simple question: “What did I actually accomplish last week?”
Not what I planned. Not what I wrote in my commit messages. What actually shipped, what was verified, and what evidence existed.
The breakthrough came from an unlikely place — watching how distributed systems work. In a well-run microservice architecture, every operation has:
Why should a one-person company be any different?
I decided to build Solo Company OS — not another project management tool, but an actual operating system for a solo operation. The core idea: Markdown is the source of truth, Rust is the runtime, SQLite is the state, and AI agents are the workforce.
Solo Company OS has three layers:
Daily operations: work orders, reports, risks, agent states, closeout evidence. This is where the work happens and gets recorded.
AI agent cognitive layer: 44 API endpoints, 207 tests, 15 safety checks. This is where agents think, plan, and decide.
The actual products: AI Storyboard Studio, BiliKnowledgeMVP, and whatever comes next. This is what generates revenue.
The layers are independent but connected through the runtime.
The heart of Solo Company OS is a Rust workspace with 5 crates:
| Crate | Purpose |
|---|---|
solo-db | SQLite runtime: work orders, agent states, reports, events, risks, snapshots |
solo-lint | Public-safe audit scanner (no path leaks, no secrets) |
solo-index | Report indexer |
solo-status | Status derivation |
solo-core | Shared utilities |
The key insight: every write operation automatically generates a runtime event. When I create a work order, update an agent state, or close a report — an event is recorded. No manual logging. No “did I remember to document this?” The system documents itself.
# Create a work order
solo-db work-order create --title "Fix login bug" --status in_progress
# The system automatically records: work_order.created
# Update an agent state
solo-db agent-state upsert --work-order-id wo-123 --agent qa --state PASS
# The system automatically records: agent_state.upserted
# Close the work order
solo-db work-order close --id wo-123 --verdict pass
# The system automatically records: work_order.closedAt any point, I can export a snapshot — a JSON document that captures the entire runtime state: what work orders are open, which agents are active, what risks exist, and what the health verdict is.
Last night, I ran the first “real operation” through Solo Company OS. Here is what the runtime recorded:
| Dimension | Count |
|---|---|
| Work Orders | 1 |
| Agent States | 4 (planner, architect, qa, security) |
| Risks | 2 (both low) |
| Next Actions | 3 |
| Reports | 1 |
| Runtime Events | 14 |
The health verdict: PASS.
Not because I said it passed. Because the system calculated it: no high-level open risks, no blocked work orders, all agents completed successfully.
I used to rely on memory and scattered notes. Now I have a database that records every decision, every verification, every risk. When someone asks “why did you do X?” I can query the runtime_events table and show them exactly when and why.
Before Solo Company OS, my AI interactions were ad-hoc. Now each agent has a role (planner, architect, qa, security, reviewer), a state machine (PENDING → RUNNING → PASS/BLOCK), and evidence attached. The agents are not just chat assistants — they are tracked workers.
Knowing that the system says “PASS” based on actual data — not my feeling about whether things are going well — is incredibly valuable. It removes the emotional bias from status assessment.
I could have built this in Python. But Rust gave me:
With AI agents tracked through the runtime, I am technically never working alone. I have a planner, an architect, a QA engineer, a security auditor, and a reviewer. They are not human, but they are tracked, accountable, and evidence-producing.
The runtime is stable. The evidence is flowing. The next step is the hardest: real business operations.
The system is ready. The question is whether I am.
Solo Company OS is open source. The runtime is in Rust, the evidence is in JSON, and the architecture is documented.
If you are a solo developer who is tired of scattered context and wants to run your operation like a well-instrumented system — take a look.
The best part? You do not need to be a Rust developer to use it. The CLI is simple, the output is human-readable, and the snapshot is a JSON file you can feed to any dashboard.
One person. One operating system. Zero context loss.
Runtime Evidence
This article was written, verified, and published through Solo Company OS Runtime Core v0.3. The full lifecycle — from work order creation to snapshot export — is recorded in the runtime database.
Schema version: 0002_runtime_core_v0.3
Health verdict: PASS