Case Studies — Same Question, Different Answer by Scale and Phase

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.

A full list of all articles in this category, with summaries and learning points, is available at the following page.

Case Studies — Article Index — Architecture Crash Course for theen.senkohome.com/arch-intro-index-case/

What is a case study in the first place

Cooking recipes are completely different for home cooking, restaurants, and cafeteria kitchens. Even for the same “make curry,” the optimal answer changes depending on scale, budget, required quality, and serving speed. You can’t cook cafeteria volumes in a home pot, and there’s no point bringing cafeteria efficiencies into a home kitchen.

Architecture case studies work the same way. Even for the same design topics (DB, auth, monitoring, etc.), the right answer changes depending on project scale, phase, and constraints — we contrast this with concrete cases.

If you pick the wrong case, a startup adopting enterprise design runs out of money and time, or an enterprise using startup design can’t pass audit — a fatal mismatch.

Why you need to learn design by case

Because “the right answer” changes completely by case

Architecture textbooks teach “design it this way” as general theory, but real projects have completely different scales, budgets, organizations, and regulations. Bring enterprise design into a startup and money runs out; bring startup design into an enterprise and audit fails. Learning by case gives you judgment axes that fit your context.

Because most failures stem from “wrong case”

Analyzing project failures, the root cause is very often mismatch — adopting a design that doesn’t fit your scale and phase — more than technical problems. Knowing the differences between cases is the shortest route to optimal tech selection.

To have criteria for judging phase transitions

A startup grows into SaaS, then evolves into enterprise core — being able to judge this phase-transition timing by numbers is a major benefit of learning by case. The habit of constantly asking “which case are we right now?” prevents both over-engineering and under-engineering.

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.

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:

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.

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.

Pitfalls and forbidden moves

The forbidden moves that turn fatal in each case:

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.

AI decision axes

1. Numerically classify your case — fix your position by people, customers, regulation.
2. Borrow the closest case’s decision structure — borrow logic, not product names.
3. Don’t skip stages — respect graduation lines, move at the size you actually are.
4. Don’t copy other cases’ right answers — answers from a different context are poison.

Measure your scale numerically before consulting AI

Asking AI “propose an architecture for our system” without scale information produces unusable answers. The right answer for a 10-person startup and a 10,000-person enterprise are opposite, so confirming these numbers before consulting AI is a precondition:

• Engineer count (now and in one year)
• Monthly active users (MAU)
• Budget range (monthly infra cost ceiling)
• Whether regulatory requirements apply (finance, healthcare, public sector)

Including these numbers in the prompt before asking AI for a design proposal dramatically improves answer accuracy. Without them, you get context-free answers like “microservices are generally recommended.”

Using case-study decision structures for AI design review

The case-study articles in this series organize the decision structure (what to prioritize, what to discard) at each scale and industry. Feeding this decision structure to AI and having it review your design lets you verify whether your design decisions fit your scale.

Concretely: input your project’s design document into AI and ask, “as a 5-person startup, are there over-engineered parts in this design?” The clearer the decision structure of the case, the more specific the feedback AI can return.

Note that AI tends toward a “more robust” bias and may recommend enterprise-grade standards for small projects. You need to know your case’s graduation lines and judge whether AI’s proposals match your actual size.

Knowledge structure of this category

This category is composed of 7 articles in total. After the overview (this article), 6 cases are arranged from smallest to largest scale.

The 6 cases split into two groups. The scale ladder (startup -> SaaS -> enterprise) is a series showing how design shifts as a project grows. Read the case closest to your current position and the one above it to see “what will be needed next.”

The special cases (public, mobile, AI product) are cases where design decisions change along an axis different from scale. Regulation and platform characteristics dominate design, so they’re referenced independently from the scale ladder.

You don’t need to read every case. 1-2 cases close to your project are enough to get the feel of applying the theory learned in other categories to your own context.

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.

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.