MyAIDevelopment · Product · Operations notes

Practical Guide for Small Teams: Solo Developers and Small Teams

The earlier documents went as far as tools for large organizations. But what a team of 1–5 people needs is not a little of everything but a few things that reliably prevent incidents.

Principles

  1. Manage less: start from the highest abstraction (Static, PaaS, Serverless).
  2. Make it reversible: a rollback path comes before automatic deployment.
  3. Make it visible: know about an outage before your users do.
  4. Protect what you cannot lose first: domain, accounts, data, secrets.

Setup by Stage

flowchart LR
    S0[Stage 0: before launch] --> S1[Stage 1: first users]
    S1 --> S2[Stage 2: paying customers]
    S2 --> S3[Stage 3: growing team]
Stage Minimum setup
0. Before launch Git + PRs, static / PaaS hosting, preview deploys, domain auto-renewal, 2FA on every account
1. First users Auto-deploy after CI tests, error tracking, uptime checks, automatic DB backups (PITR) with an agreed RPO and RTO, and one restore drill (document 07, "Backups and Recovery Objectives")
2. Paying customers One or two simple SLOs, budget alerts, a status page, feature flags, an incident record template, infrastructure moved to IaC (Terraform, OpenTofu, etc.) with plan as a PR check (document 03, "Infrastructure as Code Too")
3. Growing team Documented deployment procedure, template repository, on-call rotation, cost tag policy, IaC drift checks, a review of whether cross-region backups are needed

Example Combinations

Product type Starting combination Next step
Docs · landing page GitHub Pages or Cloudflare Workers Static Assets CDN cache rules, analytics
Web app + API Vercel / Netlify (frontend) + serverless container (API) + managed DB. Cap max instances to fit the database connection limit, or add a connection pooler (document 01) Staging environment, canary
Mobile app + backend TestFlight · closed test + serverless backend Phased release, server feature flags
SaaS for the Korean public sector Start by checking for a CSAP-certified cloud (verification planned to move to the NIS in 2027-07, document 02) Reflect the required certification grade

Plan conditions change. Check commercial-use permission, billing units and provider roadmaps with the checklist in document 01.

Minimum Pipeline

name: ci
on: [push, pull_request]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<commit-sha>
      - run: npm ci
      - run: npm test
      - run: npm run build

For deployment, you can start with the hosting provider's Git integration and no extra scripts. What matters is a structure where nothing deploys if tests fail.

Operating Habits for Solo Developers

Bad Example / Good Example

Bad:  "I'm alone, so I need neither staging nor tests." → You first learn of outages from user reports.
Good: Check the preview deploy yourself, and ship to production only when CI tests pass.
      Uptime checks tell you before users do.

Bad:  Create domain, cloud and store accounts all with one personal email and no 2FA.
Good: Use a work account with 2FA, keep recovery codes safe, and get alerts before payment methods expire.

30-Minute Pre-Launch Checklist

How to Revisit This Track

Read whatever hurts most right now. Scared of deploying: 04. Learning about outages late: 07. Scared of losing data: the backups and recovery objectives in 07. Infrastructure built by hand: infrastructure as code in 03. Scared of the bill: 09. Stuck in app review: 05.

References