Making Software Like Lego: How Aspire Brings the Pieces Together

Recently Andrej Karpathy posted about the reality of building web apps in 2025. His point was simple: it’s not really about writing code anymore. It’s about integration. Plumbing. Orchestration. Config.

“It’s not even code, it’s… configurations, plumbing, orchestration, workflows, best practices.”

And he’s right.

To build even a basic web app today, you need to stitch together:

• Frontend + backend frameworks
• Hosting (CDN, HTTPS, domains)
• A database
• Auth
• Blob storage
• Email
• Payments
• Background jobs
• Monitoring
• CI/CD
• Secrets
• And on and on…

It’s not just overwhelming — it’s fragile. Every connection point between systems is a potential failure. Every “simple integration” hides config files, CLI flags, environment variables, and docs scattered across five browser tabs.

Even if you know what to do, getting all the parts to work together is painful. Especially once you step outside the boundaries of the getting-started guide.

To make this easier, many companies have built vertical platforms — opinionated, end-to-end experiences that hide the plumbing.

Think Firebase, Heroku, Vercel, or even larger internal developer platforms at big companies. These platforms aim to simplify the full stack: you write some code, push a button, and everything just works.

And that approach works — until it doesn’t.

The trade-off is composability. Once you need to do something the platform didn’t anticipate, you’re stuck. There’s no escape hatch. You can’t easily swap out the database or customize the deployment pipeline or hook in your company’s internal tools.

This is, in my opinion, why Kubernetes ended up winning the container orchestration wars. It wasn’t the easiest option. But it was composable. It gave teams a system they could extend, adapt, and build on.

Aspire is taking that same approach — not to containers, but to the entire application lifecycle.

Aspire gives you a model for expressing your entire application — not just the code, but everything around it. Every service, every dependency, every piece of infrastructure your app touches.

The building blocks of this model are resources. Each resource describes a component of your system: an executable, a container, a cloud service, a queue, a database, whatever.

These resources expose clear contracts — how they’re configured, what they connect to, how they get executed or deployed.

And then we wire them together.

In Aspire, connecting a web app to a database isn’t “set this env var and hope it works.” It’s:

That reference isn’t just a symbolic link — it’s a contract. The system knows what it means. And when you run or publish the app, Aspire ensures everything gets wired up correctly: secrets, connection strings, port mappings, volumes, and all the platform-specific details that usually live in YAML or documentation.

Think of Aspire less like a vertical stack, and more like a set of interlocking pieces.

• You want to define how your organization uses Redis? Create a hosting integration.
• You want to wrap email sending with observability and retries? Model it as a resource.
• You want to plug in your platform’s database provisioning? Write a custom publisher.

We’re not trying to hide complexity. We’re trying to make it composable. So you can build like you do with LEGO — snap things together and know they’ll fit, even if they come from different vendors or teams.

Aspire isn’t a platform with batteries included. It’s a platform model with extension points.

Karpathy also made another important point:

“A lot of glory will go to whoever figures out how to make it accessible and ‘just work’ out of the box, for both humans and, increasingly and especially, AIs.”

We think Aspire is that platform.

It gives humans a system with strong contracts, discoverability, and reusable building blocks.

And it gives AIs a structured, inspectable model of the application they’re helping you build.

Instead of asking an LLM “how do I connect a backend to a PostgreSQL container,” you can ask “what resources are defined in this app model?” or “can you help me extend this hosting integration?”

That’s a fundamentally different experience. It moves us past plumbing and back to design.

The complexity of modern web apps isn’t in the features — it’s in the connections.

We’ve spent years building better component models for code. Aspire is about bringing that same rigor and reusability to everything else: infrastructure, configuration, orchestration.

Other platforms offer ease — but at the cost of flexibility.

Aspire is aiming for something bigger: a composable, extensible system you can grow with. A platform where your app is built from resources that snap together, not duct-taped scripts and guesswork.

This is how we scale software in 2025 — not just by hiding the complexity, but by modeling it.