Cloud and AI Architecture: Case Studies · Part 1 of 4

Three Companies, Three Stages

Who these companies are, and why three AI products end up with 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. Each case study after it can be read on its own.

Why stage changes the answer

A three-person team validating a product idea and a two-hundred-person team serving regulated enterprise customers face different problems, even when both call what they're building "an AI platform." Money and engineering hours differ, and so does the question the company is trying to answer. Architecture that ignores which question is live produces systems that are either too fragile to sell or too expensive to have built.

The three companies below sit at three different stages.

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.

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 has to absorb.
• 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.