Meta-research · July 18, 2026
The solopreneur infrastructure growth map: what to change, and when
Seven platform categories become one operating map—from a prototype that should fail safely to a revenue-producing system whose recovery, limits, and unit economics have been tested.
Method
What this comparison measures
- Synthesize the six source studies using the same cost-control, observability, portability, and operational-burden criteria.
- Use stages defined by evidence—not vanity user counts: prototype, first users, first revenue, predictable growth, and operationally critical.
- Model monthly bands rather than point estimates because databases, media, AI, and traffic shape dominate the exact bill.
- Recommend a platform class and a migration trigger, never a universal vendor winner.
The first architecture optimizes for a cheap mistake
Before users, the correct failure mode is usually a hard stop. A builder, free BaaS, scale-to-zero runtime, and prepaid model budget let a founder test demand without maintaining a server or accepting an uncapped invoice.[1]
Repository ownership, data export, domain control, and documented environment variables are more important than theoretical scale. They preserve the option to move after the product discovers its real workload.
| Stage | Optimize for | Required evidence | Good default class |
|---|---|---|---|
| Prototype | Speed and hard cost boundary | Build works; data exports | Prompt builder + free managed backend |
| First users | Errors and supportability | Logs, latency, per-feature usage | Managed PaaS / BaaS |
| First revenue | Recovery and unit economics | Backups, restore, cost per action | Paid managed platform |
| Predictable growth | Efficiency and bottlenecks | Capacity profile and measured resource hours | Optimized PaaS, cloud service, or VPS |
| Operationally critical | Isolation and recovery | SLOs, fault tests, tested failover | Deliberate cloud or multi-node design |
The monthly bill is a band, not a ladder
A content product can reach large traffic while staying close to an edge free tier. A small AI product can spend hundreds of dollars with a few power users. A realtime or media backend can cross egress and connection quotas before compute looks busy.
The bands below combine the preceding studies. Use them for budget conversations, not forecasts. The upper edge includes paid telemetry, backups, and safer limits alongside the cheapest runtime.
Migration triggers that are evidence, not anxiety
Leave a prompt-to-app runtime when missing logs or cost controls block support, not because generated code is unfashionable. Leave a PaaS when measured steady-state resource cost or a required primitive justifies the operational step. Leave a managed database when its premium exceeds the tested cost of running and recovering the alternative.
Rent a GPU after an open model passes the product evaluation. Buy one after rented utilisation stays high. Move from VPS to dedicated CPU after measurements show sustained CPU contention. Add redundancy after the recovery objective demands it—not as architecture decoration.
| Current class | Evidence-based trigger | Likely next move | Proof before migration |
|---|---|---|---|
| Prompt-to-app | Cannot explain incidents or cap spend | Owned repo on managed PaaS | Repeatable build and data export |
| Managed PaaS | Steady measured premium exceeds operator cost | VPS or narrow cloud service | Load profile and automated recovery |
| BaaS | Dominant meter or missing database primitive | Composed services or self-host | Data migration and restore rehearsal |
| Direct LLM API | Stable costly demand; open model passes eval | Rented GPU | Quality, throughput and fallback test |
| Rented GPU | High sustained utilisation | Owned GPU | Power, VRAM, depreciation and downtime model |
| Shared VPS | Measured contention or capacity ceiling | Dedicated vCPU / bare metal | Same workload benchmark and recovery plan |
The one-person operating contract
Every production stack should fit on one page: components, owner, monthly envelope, hard limits, alert thresholds, data location, backup location, recovery steps, and deletion steps. This inventory connects product risk to an operating action more directly than a complex architecture diagram.
Review it after every launch and monthly invoice. Replace model assumptions with observed resource series. If a component cannot be monitored, capped, restored, or deleted predictably, it is not yet safe merely because deployment succeeded.
- One billing inventory: every paid resource and its deletion condition.
- One cost model: price per product action and a launch-spike envelope.
- One recovery test: restore data and service into an empty environment.
- One capacity profile: operation latency, resource headroom, and the first limiting dependency.
Source register
Specifications and prices change. The links make this snapshot auditable.
Sources and commercial facts were checked on 2026-07-18. Prices exclude tax unless the source says otherwise.
- Prompt-to-app SRE field guide ↗CapacityLab · benchmark
- Railway vs Fly.io ↗CapacityLab · benchmark
- Big cloud for one person ↗CapacityLab · benchmark
- VPS, VDS, or dedicated? ↗CapacityLab · benchmark
- API, rented GPU, or owned GPU ↗CapacityLab · benchmark
- Supabase costs and alternatives ↗CapacityLab · benchmark