Startups: The Ecosystem and How They're Funded · Part 8 of 8

The Cloud and AI Shift

How cloud computing lowered the cost of starting up, and why investors are drawn to AI-first companies.

Cloud computing

Before cloud computing was an option, a startup that needed to serve traffic had to buy it: servers, networking equipment, storage, and often space in a physical data center to put all of it, plus the operations staff to keep it running. That spending happened up front, in large chunks, before a single customer had confirmed the product was worth building. If demand came in lower than expected, the company had already spent the money finding that out.

Capital expenditure vs. operating expenditure. Buying servers outright is capital expenditure (capex): a large upfront cost that becomes an asset the company owns and has to maintain. Renting compute from a cloud provider, billed by the second or hour, is operating expenditure (opex): a smaller, ongoing cost that scales with usage. Cloud computing moved infrastructure spending from capex to opex, which lowered what an early-stage company had to commit before knowing whether the product worked.

Several changes removed most of the reason a startup would run its own hardware:

On-demand infrastructure: compute, storage, and networking are available in minutes, against the weeks or months it took to order, ship, and rack physical hardware.
Consumption pricing: pay for what gets used, so an idea with three users can cost a few dollars a month to keep running while it's being validated.
Managed services: a database, a queue, or an identity system that would once have needed a specialist to run is available as an API call, with the provider handling patching, failover, and backups.
Global, elastic infrastructure: a startup can serve a customer on another continent, and capacity can grow or shrink with demand instead of being sized in advance for a guess about peak load.

These are why startups reach for managed services early instead of running things themselves. Every hour spent operating a database is an hour not spent finding out whether the product is worth having a database for, and at the pre-seed or seed stage, that trade favors buying the capability. A managed service is usually faster to start with and lets a small team cover more ground, at the cost of less control, some lock-in to the provider, and dependence on someone else's system staying reliable. This site's Core Cloud Architecture series picks up from here, walking through the building blocks this trade-off applies to one at a time, with AWS, GCP, and Azure examples.

AI-first startups

An AI-first startup is one where a model capability is the product itself, creating value that would be impossible without AI. The category spans foundation models, AI agents (covered in this site's Agentic AI series), AI-native SaaS and developer tooling, AI infrastructure, robotics and embodied AI, and scientific AI such as biology and materials science.

Investors are drawn to these companies by large addressable markets, rapid product development, the disruption of labor-intensive workflows, new product categories, and the potential for network effects and proprietary data that compound with usage. Each comes with a matching risk: model commoditization, dependence on model providers whose pricing and availability a startup doesn't control, high and sometimes unpredictable inference cost, weak differentiation when the product is a thin layer over someone else's API, and the difficulty of evaluating whether an AI system is working correctly at all. The money follows: in 2025, AI companies took 65.4% of US venture deal value but 39.4% of deals (PitchBook-NVCA Venture Monitor, Q4 2025), so the dollars are concentrated in a small number of very large rounds.

Wrapper or durable company?

The question a technical investor keeps returning to is whether the company would survive a better, cheaper model shipping from a competitor next quarter. A thin interface over a general-purpose model API is fast to build and just as fast to replicate. A durable AI company usually has at least one of the following working in its favor:

A proprietary workflow or process the product is embedded inside, not sitting next to
Data that's theirs, accumulating with usage, and not easily reproduced by a newcomer
Domain expertise encoded into the product that a general-purpose model doesn't have on its own
Deep integration into a customer's existing systems, raising the cost of switching away
An existing distribution channel or customer base a new entrant would have to build from scratch

The test. If the entire product would disappear the day a foundation-model provider shipped this feature natively, that's the wrapper case. If the product would survive and be a little less impressive for a while, that's the durable case.

This site's Generative AI Architecture series covers the technical side of the same question: how RAG, fine-tuning, agents, and evaluation get built, and which of those choices tend to create the durability described above.

Previous ← Where Startups Are Built