About this article
This article is the entry point of the “Case Studies” category in the Architecture Crash Course for the Generative-AI Era series, surveying real-world contrasts by scale and phase.
The chapter is for grabbing “the right answer for this case”, not “the right answer.” Three typical cases — individual/startup, mid-sized SaaS, large-enterprise core systems — and how the same design topics (deploy, DB, auth, monitoring) shift across them, organized so you can grab the answer closest to your project.
More articles in this category
Three typical cases
In the three cases below, we contrast how the same topics (deploy, DB, auth, monitoring, etc.) get different answers. Even without an exact match, thinking from your closest case is practical.
flowchart LR
SU["Individual / Startup<br/>1-5 people<br/>Top priority: speed to market"]
SAAS["Mid-sized SaaS<br/>5-30 / paid customers<br/>Top priority: availability"]
ENT["Enterprise core systems<br/>1000+ employees<br/>Top priority: governance"]
SU -->|customer growth, scaling| SAAS
SAAS -->|larger scale, regulation| ENT
SU -.- L1["Vercel/Supabase/<br/>Auth0/Stripe"]
SAAS -.- L2["AWS/IaC/<br/>Datadog/SOC2"]
ENT -.- L3["Multi-AZ/<br/>Dedicated SRE/audit"]
classDef startup fill:#dcfce7,stroke:#16a34a;
classDef saas fill:#dbeafe,stroke:#2563eb;
classDef ent fill:#fae8ff,stroke:#a21caf;
class SU startup;
class SAAS saas;
class ENT ent;| Case | Size | Top priority |
|---|---|---|
| Individual / Startup | 1-5 | Speed to market |
| Mid-sized SaaS | 5-30, paid customers | Availability, low ops overhead |
| Enterprise core systems | 1000+, audit-mandatory | Governance, long-term ops |
Side-by-side: same question, different answer
Lining up three cases makes it visceral that a 10x difference in scale produces a 10x difference in design. Representative contrasts:
| Topic | Individual / Startup | Mid-sized SaaS | Enterprise core |
|---|---|---|---|
| Deploy | Vercel / Netlify | ECS Fargate / Cloud Run | Hybrid, phased migration |
| DB | Supabase / Neon | Aurora / Cloud SQL | Oracle / SQL Server / Postgres |
| Auth | Clerk / Auth.js | Auth0 / Cognito (SAML) | Azure AD / Okta + SAML |
| Monitoring | Sentry only | Datadog / New Relic | Dynatrace / Splunk + SLA |
| Language | TypeScript only | TS / Go / Python | Java / C# / TS |
| Design principle | Speed-first | Managed + IaC + SLO | Fit to Standard + phased migration |
This isn’t about which is “better.” The point is different contexts produce different optimal answers.
Per-case numeric gates and graduation lines
Note: industry rates as of April 2026. Periodic refresh required.
A table to numerically classify “which case am I?”. Also useful as phase-transition guidelines.
| Metric | Individual / Startup | Mid-sized SaaS | Enterprise core |
|---|---|---|---|
| Engineers | 1-5 | 5-30 | 30+ (per BU) |
| Monthly infra cost | < $300 | $300-$30k | $30k+ |
| Paid customers | 0-100 | hundreds-thousands | tens of thousands+ |
| Availability SLO | 99% / 99.9% | 99.9-99.95% | 99.99%+ |
| Audit log retention | 30 days | 1-3 years | 7 years (J-SOX) |
| MFA mandatory | Recommended | All users | All employees (no exceptions) |
| Project duration | < 3 months | 6-12 months | 2-5 years |
| Investment | < $100k | $100k-$1M | $1M-$1B |
Graduation lines: startup -> mid-sized SaaS at “100+ paid customers or $300+/month”; mid -> enterprise at “30+ engineers or entering a regulated industry.” Skipping a stage creates design inconsistency and burns the project.
Numerically classify your case. Mixing two cases is the realistic answer near a boundary.
Per-case forbidden moves
The forbidden moves that turn fatal in each case:
| Case | Forbidden move | Famous example |
|---|---|---|
| Individual / Startup | Microservices, K8s, custom auth | Quibi 2020 ($1.75B raised, dead in 6 months) |
| Startup | ”For the future,” full AWS VPC / IAM / RDS | Product front page blank for 3 months |
| Mid-sized SaaS | < 30 people on EKS + 12 microservices | Segment 2020 reversal — consolidate to Fargate monolith |
| Mid-sized SaaS | Analytical queries on production DB | Customer-perceived speed degrades — churn cause |
| Enterprise | Big-bang rewrite (full replacement) | Hershey 1999 Halloween ($100M loss), Healthcare.gov 2013 ($2B added) |
| Enterprise | Heavy customization of packages | Lidl SAP eLWIS 2018 (EUR 500M loss, project killed) |
| All | Importing another case’s right answer verbatim | Oracle at a startup blowing the budget; Supabase at an enterprise re-doing 6 months of audit work |
Mismatching the case is fatal even when the technical logic is perfect. “Copying enterprises” and “copying startups” are both poison — that is the substance of case study work.
Other people’s right answers are poison for your company. Designs that get scale and context wrong always blow up.
Which case to read
Classify your project with these questions to find the main case to anchor on:
- Are users paying?
- No -> Individual / Startup.
- Yes -> next question.
- 1000+ employees or regulated industry (finance, healthcare, public)?
- Yes -> Enterprise core systems.
- No -> Mid-sized SaaS.
For projects in between (e.g. 200-employee SaaS), the realistic move is reading both nearby cases and combining elements.
Don’t look for an exact match. Borrow the closest case’s thinking — that’s the smart usage.
Mindset for reading
Each case study is a concrete prescription for “at this scale, this.” But technology shifts. Product names and specific service names are snapshots from authoring time, and other options may be mainstream a few years later.
What matters is each case’s decision structure. Grasp the logic behind “why pick this at this scale?” and “why avoid this at this scale?”, and you can apply the same criteria when new products show up.
The right takeaway from this chapter is “the decision structure,” not the product name.
A startup that “adopted Oracle because big companies use it for safety” nearly ran out of money on monthly licensing. An enterprise SaaS migration that “copied a startup’s setup” with Supabase had to rebuild after 6 months once audit requirements hit. Don’t borrow the answer; borrow the decision structure — a feel that doesn’t form without falling over a few times in the field.
How to make the final call
The substance of case studies is the recognition that the same design questions get opposite answers depending on scale, phase, and organization. Bringing a startup answer (Supabase, Vercel, minimal DIY) into an enterprise produces audit re-do; bringing an enterprise answer (Oracle, SAP, strict governance) into a startup blows the budget. The moment you borrow someone else’s right answer, it turns to poison. Numerically classify “which case is my project closest to?” by engineer count, paid customers, monthly infra cost, regulatory requirements, and borrow the closest case’s decision structure. Don’t seek exact matches; the boundary calls for combining two cases.
The other decisive axis is the reading discipline of “take home the decision structure, not the product name.” Technology shifts, product names are snapshots, but the logic of “why this at this scale” is universal. Skipping graduation lines also matters — jumping straight from startup to enterprise topology is over-investment, and the reverse causes firestorms.
Selection priority
- Numerically classify your case — fix your position by people, customers, regulation.
- Borrow the closest case’s decision structure — borrow logic, not product names.
- Don’t skip stages — respect graduation lines, move at the size you actually are.
- Don’t copy other cases’ right answers — answers from a different context are poison.
“Numerically pin down your case, borrow the decision structure.” Importing other people’s right answers blows things up.
Summary
This article surveyed scale and phase contrasts across the three cases, plus graduation lines, the cost of mismatch, and the reading mindset.
Classify cases numerically and borrow the decision structure. Product names change, but the logic does not. The realistic answer for using these case studies in 2026.
The next article covers Individual / Startup — the configuration that prioritizes speed to market with 1-5 people and the concrete selections that avoid over-engineering.
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
📚 Series: Architecture Crash Course for the Generative-AI Era (80/89)