Cloud and AI Architecture: Case Studies · Part 1 of 4
Three Companies, Three Stages
Who these companies are, and why the same job title produces three different architectures.
Earlier series covered startup fundamentals, venture funding, and the individual building blocks of cloud and AI architecture: compute, storage, databases, messaging, retrieval, and model platforms. The three case studies that follow assemble those pieces into complete systems, one per company, each designed three times over, once per major cloud provider.
This article introduces the companies. Read it first if you want the context for why the three designs differ so much. Each case study after it is written to be read on its own, without assuming you've read the others.
Why stage changes the answer
A three-person team validating a product idea and a two-hundred-person team serving regulated enterprise customers are not solving the same problem, even when both describe what they're building as "an AI platform." The available money is different, the available engineering hours are different, and above all the question the company is currently trying to answer is different. Architecture that ignores which question is live produces systems that are either too fragile to sell or too expensive to have built.
So the three companies below sit at three points on that curve.
Casewell — pre-seed / seed
An AI research assistant for small and mid-size law firms. An associate asks a question in plain language and gets back relevant case law, cross-referenced against the firm's own past filings and internal memos, with citations to both. Five to ten employees, three of them engineers, fewer than a hundred paying firms, priced as SaaS. The company is trying to find out whether lawyers trust and keep using the product, and every infrastructure decision is weighed against whether it helps three engineers learn that faster.
Sentrio — Series A
AI-assisted triage and investigation for security operations center (SOC) teams. It ingests a customer's existing logs and alert streams, correlates related signals into a single incident, summarizes what happened in plain language, and suggests next investigative steps. Fifty to a hundred employees, twenty-five to forty of them engineers, hundreds to low thousands of customers, and meaningful annual recurring revenue. The product works; what's unproven is whether the company can sell it repeatedly to larger buyers whose procurement process gates every deal.
Virelane AI — late-stage / growth
An enterprise AI platform that reads and reasons over a customer's own internal documents: loan files at banks, claims at insurers, clinical documentation at hospital systems, case files inside government agencies. Several hundred to a few thousand employees, revenue in the hundreds of millions, customers whose compliance departments can veto a vendor outright. The open questions are operational: whether the platform holds up under audit, across jurisdictions, at a margin the company can defend to an investor.
| Case study | Stage | What it does | Dominant concern |
|---|---|---|---|
| Casewell | Pre-seed / seed | AI research assistant for small and mid-size law firms | Ship fast, prove the product works, don't over-build |
| Sentrio | Series A | AI-assisted triage and investigation for security operations teams | Grow reliably, sell to enterprises, pass their security reviews |
| Virelane AI | Late-stage / growth | Global enterprise AI platform for regulated financial, healthcare, and government customers | Multi-region resilience, compliance, cost governance at scale |
How each case study is laid out
All three follow the same shape, so the differences between them are easy to compare directly:
- The company: what it sells, to whom, at what size.
- Usage pattern: the shape of the traffic the system actually has to absorb, which drives more design decisions than headcount does.
- Requirements: functional, non-functional, and the risks that dominate at this stage.
- A full architecture on AWS, then the same requirements re-derived on GCP and on Azure from each provider's own service model.
- A capability comparison table across the three clouds, including the capabilities deliberately left unused.
- Architecture decision records: the decision, why, what else was considered, the trade-off accepted, and the condition that would force a revisit.
- Due diligence questions: what an investor's technical diligence call or a customer's security review would ask, and how the design answers.
A closing article, The Founder's Decision Framework, pulls the seven recurring questions out of all three and shows how the right answer to each one moves with stage.