Startup Business Plan - 1x 4x A100 80GB Server (Colocation, 4-Year Financing)¶
1. Executive Summary¶
This plan models a focused startup launch with one refurbished GPU server:
- 1x server with 4x NVIDIA A100 80GB (refurbished)
- Hosted in colocation (mid flat assumption: EUR 349/month)
- Financed over 4 years (48 months)
- Primary channel: marketplace GPU rental
The revalidation result is clear:
- The setup can be cash-positive under optimistic revenue realization.
- Under conservative host-payout and FX-normalized assumptions, it is near break-even to negative.
- Therefore this startup is financeable only with strict entry conditions, a reserve, and a stop-loss rule.
2. Concept and Offer¶
2.1 What is sold¶
- 4x A100 80GB compute capacity
- Marketplace-first listing strategy
- Reliability differentiators: clean colocation power, uptime discipline, fast support
2.2 Why this concept¶
- A100 80GB keeps broad model compatibility
- Single-server scope keeps operational complexity manageable next to full-time work
- 4-year term lowers monthly debt service versus 3-year financing
3. Revalidated Core Assumptions¶
| Parameter | Value | Source / Note |
|---|---|---|
| Market anchor (gross) | 1.206 USD/GPU-h | Recent 7-day snapshot median (global_verified_1x_a100_80gb_rentable) |
| Host payout factor | 0.85 | Planning assumption for net host revenue vs listed gross |
| FX conversion | 0.92 EUR/USD | Planning assumption |
| Effective host rate (base) | 0.943 EUR/GPU-h | 1.206 * 0.85 * 0.92 |
| GPUs per server | 4 | Fixed |
| Runtime basis | 730 h/month | Standard planning month |
| Refurb GPU price (high) | EUR 16,000 per GPU | Pessimistic purchase anchor |
| Server add-on | EUR 10,000 | Chassis, CPUs, RAM, NVMe, rails, parts |
| Base principal | EUR 74,000 | 4 * 16,000 + 10,000 |
| Warranty add-on (modeled) | EUR 3,256 | 2.0% * 74,000 * 2.2 years |
| Financed principal | EUR 77,256 | Base + warranty add-on |
| Financing | 8% annual, 48 months | Planning case |
| Monthly financing payment | EUR 1,886 | PMT model |
| Colo flat | EUR 349/month | Mid scenario |
| Maintenance reserve | EUR 200/month | EUR 600/GPU/year |
| Insurance | EUR 185/month | 3% per year on EUR 74,000 |
4. Monthly Unit Economics (Revalidated)¶
4.1 Revenue scenarios¶
- Formula:
Monthly revenue = rate_per_gpu_h * 4 * 730 * utilization - OPEX excl. finance:
349 + 200 + 185 = EUR 734/month - Total incl. financing:
734 + 1,886 = EUR 2,620/month
| Scenario | Effective host rate (EUR/GPU-h) | Net @70% | Net @80% | Net @90% |
|---|---|---|---|---|
| Conservative (payout+FX normalized) | 0.943 | -692 | -417 | -142 |
| Gross-parity reference (optimistic) | 1.206 | -155 | +197 | +549 |
| Upside execution case | 1.350 | +139 | +534 | +928 |
Interpretation:
- The current concept is very sensitive to realized net hourly rate.
- At 80% utilization, break-even needs about EUR 1.12/GPU-h net host rate.
4.2 Break-even thresholds¶
Given fixed monthly cost of EUR 2,620:
- Break-even utilization at EUR 0.943/GPU-h: about 95.1%
- Break-even utilization at EUR 1.206/GPU-h: about 74.4%
- Break-even host rate at 80% utilization: about EUR 1.122/GPU-h
4.3 Four-year rate-compression stress (@80% utilization)¶
Stress setup:
- Start host rate: EUR 1.206/GPU-h
- Fixed monthly load (OPEX + financing): EUR 2,620
- Utilization fixed at 80%
| Year | Flat rates (0%/yr decline) | Mild decline (10%/yr) | Medium decline (20%/yr) | Severe decline (30%/yr) |
|---|---|---|---|---|
| Y1 net EUR/mo | +197 | +197 | +197 | +197 |
| Y2 net EUR/mo | +197 | -85 | -366 | -648 |
| Y3 net EUR/mo | +197 | -338 | -817 | -1,240 |
| Y4 net EUR/mo | +197 | -566 | -1,178 | -1,654 |
Interpretation:
- This concept tolerates small compression, but not persistent double-digit yearly rate erosion.
- If rate decline materializes, expansion must be delayed and card-generation upgrade timing becomes critical.
5. Startup Capital and Liquidity¶
5.1 Immediate cash needs¶
| Item | Amount (EUR) |
|---|---|
| Contracted monthly payment (financing) | 1,886 |
| OPEX excl. financing | 734 |
| Total monthly fixed load | 2,620 |
| Recommended reserve floor (6 months fixed load) | 15,720 |
5.2 Funding logic¶
To avoid personal financial stress:
- Keep at least 6 months fixed-load reserve inside the company account.
- Founder monthly top-up is allowed in ramp months but must be capped by policy.
- No second server before 3 consecutive months above the go-threshold (see section 8).
6. Operating Model (Low-Complexity)¶
- Keep to one server and one listing profile at launch.
- Use strict uptime monitoring and fast ticket response as service quality edge.
- Standardize one stable software stack; avoid frequent image churn.
- Track daily: occupancy, realized net EUR/GPU-h, support incidents, downtime.
7. Legal and Risk Posture¶
7.1 Entity and liability¶
- Operate through a limited-liability structure (UG/GmbH path).
- Avoid unlimited personal guarantees where possible.
- No private co-signing for colo and supplier contracts.
7.2 Main risks¶
- Revenue compression risk (market rates drift down)
- Utilization risk (insufficient occupancy)
- Hardware incident risk (GPU/server failure)
- Counterparty risk (colo SLA quality, support quality)
7.3 Controls¶
- Contract checkpoints before signature (termination, default, replacement, buyout terms)
- Insurance active from day one
- Predefined stop-loss and rollback decision gates
8. Go / No-Go Rules¶
Proceed with this specific high-price 4-year concept only if all are true:
- Signed all-in hardware quote supports modeled principal (or better).
- Realized net host rate expectation is at least EUR 1.12/GPU-h at 80% utilization.
- Company reserve at launch is at least 6 months fixed-load.
- Contracts do not force uncapped personal downside.
Stop-loss trigger after launch:
- If 2-month rolling net is below minus EUR 400/month, freeze expansion and execute cost/rate correction plan.
9. 90-Day Launch Plan¶
| Phase | Duration | Output |
|---|---|---|
| Contracting and legal setup | Weeks 1-3 | Entity, insurance, signed finance + colo contracts |
| Build and deployment | Weeks 4-7 | Installed server, monitoring, baseline burn-in |
| Listing and optimization | Weeks 8-10 | Live listing, measured utilization and realized pricing |
| Decision gate | Weeks 11-12 | Continue / optimize / stop based on measured unit economics |
10. Expansion and Upgrade Decision Matrix¶
10.1 Trigger matrix for next server purchase¶
| Decision | Required trigger set | Action |
|---|---|---|
| Add another A100 80GB server (same generation) | Last 3 months: utilization >= 82%; realized host rate >= EUR 1.15/GPU-h; DSCR >= 1.25; reserve >= 9 months fixed-load after down payment | Buy server #2 with same generation and same operating stack |
| Wait / optimize current server | Any one metric below trigger but net near break-even (>-200 EUR/mo) | No new hardware; focus on pricing, uptime, listing quality, occupancy |
| Pivot to newer generation for next purchase | Last 2 months lost demand due to VRAM/perf requirements OR realized A100 rate drops below EUR 1.05/GPU-h while demand stays high for newer cards | Do not add another A100 unit; run replacement economics for next-gen cards |
| Freeze scaling | 2-month rolling net <= -400 EUR/mo | Stop expansion; execute stop-loss remediation only |
10.2 Proposal: when to buy next-generation cards¶
Use this upgrade rule for server #2 decision:
- Build a 48-month model for both options:
- Option A: another 4x A100 80GB server
- Option B: 1x newer-generation server (comparable 4-GPU class)
- Use conservative assumptions for both:
- Same utilization assumption
- Net host rate (after payout and FX), not list price
- Full OPEX + insurance + maintenance + financing
- Buy newer generation only if all hold:
- Net monthly cashflow improves by at least EUR 250 versus Option A at 80% utilization
- Break-even utilization is at least 8 percentage points lower than Option A
- Liquidity buffer remains >= 9 months fixed-load after purchase
- Contract terms do not increase personal downside
This keeps decisions economics-first and avoids buying new cards only because of hype.
10.3 Scale-gate table (server #2/#3/#4)¶
Use this gate table before each new server financing decision.
| Next server | Typical earliest timing | GO (all must be true) | WAIT / NO-GO |
|---|---|---|---|
| #2 | Month 6-9 | Last 3 months utilization >= 80%; net after finance positive each month; reserve >= 6 months fixed-load after order; no unresolved critical incidents | Any metric below threshold; delay and optimize pricing/ops first |
| #3 | Month 12-18 | Fleet-level net positive for last 3 months; utilization stable >= 80% on both existing servers; reserve >= 9 months fixed-load after order; 48m scenario still feasible under stress assumptions | One server carries the other, or reserve drops below floor |
| #4 | Month 18-30 | Standardized operations (monitoring, incidents, spare strategy) in place; fleet-level DSCR >= 1.25; stress case remains non-negative at >= 70% utilization; no contract downside increase | Operational instability, weak stress-case resilience, or new personal downside clauses |
Practical rule:
- Scale only after proof from measured operating data, never only from optimistic projections.
Appendix: Supporting Analysis¶
See appendix analyses for the detailed revalidation model and risk controls.
References & Sources¶
tmp/market-snapshots/vast_market_snapshots.csv(latest local snapshots)build/vast_focus_a100_80gb.md(latest focused economics run)- Vast.ai API reference
tooling/marketplace/vast_market_cron_snapshot.pytooling/marketplace/vast_card_focus_report.py