Opinionated by Design: How the way we talk about Aspire has evolved in its first year
This is the first in a series of posts about Aspire — how a year of refining our messaging from buzzwordy to dev-first has helped shape the product, its roadmap, and our vision for the future.
About 18 months ago, in a .NET team all-hands, Damian Edwards showed a demo of “.NET Aspire — An opinionated, cloud-native stack for building observable, production-ready, distributed applications” ahead of its preview launch. Like any good Product Manager, the first thing I did was side-chat a colleague aaaaand… complain.
Fast forward six months — just under a year ago — and I was sitting at Microsoft Build, right after Damian and David Fowler’s “Intro to Aspire” session, talking to my soon-to-be-boss about how their pitch took 15 minutes and still didn’t make sense. It wasn’t their fault — they were too busy building the thing to argue about words! But that was the moment I officially decided to take the leap — after six years (!!!) — to a new team, new product, and a new challenge: making Aspire make sense.
The first goal seemed simple — come up with a tagline that didn’t immediately trigger the response, “WTF does that even mean?”. Least surprising spoiler of all time: it wasn’t simple. What I actually cracked open was a very large can of worms — each with its own opinions, history, and context, none of which wanted to be distilled into a single sentence. 🪱
The good news is that by then I (mostly) understood Aspire’s value — and the team knew how insanely helpful it was, especially for developers who don’t consider themselves cloud-native experts (like me 🙋♀️). We all also had so many ideas of ways Aspire could solve real day-to-day problems for devs. Over the last year, what started as “fixing the tagline” turned into something much bigger: a journey that’s pushed us to better understand what Aspire actually is, and why we’re building it.
As we approach Aspire’s first birthday — and as we map out where we’re heading next — I thought it would be fun to share some of the lessons, mental shifts, and chaos behind how Aspire’s messaging has evolved. And more importantly, how that evolution is shaping the product itself.
🪱 The first worm: “Cloud-native” doesn’t mean anything (to most of us)
I have had a LOT of rants since joining Aspire, but my first is still probably my favorite — most people don’t think of themselves as “cloud-native developers”, and saying “cloud-native” in the tagline is hurting Aspire’s appeal. I mean… what even IS cloud-native? There’s the CNCF, but they keep talking about Kubernetes. Do I need to know how Kubernetes works to use Aspire? Isn’t that all YAML?!? I just have a couple of APIs and a website, I’m not cloud-native!!! All I want is to debug my code and stick it on the cloud and have it not crash if traffic spikes!
Technically, cloud-native architecture is a reasonable way to describe why we built Aspire in the first place, but it felt so exclusive. Maybe a CTO would see the term and “get it”, but not the dev who would be using Aspire every day. My argument became “if your app talks to the internet, Aspire helps you”.
But that left us without a word we could use to describe our target audience. “But what types of apps? Web apps? APIs? Performant ones? Observable? Modern? Is Aspire a cloud-native stack? Is it even a stack or is it for cloud-native stacks?!?!”
This led to the first big shift of how we thought about Aspire — it isn’t a “cloud-native/web/performant/modern stack”, and it isn’t for a particular type of app. Aspire brings your stack, whatever it is, together in a composable and modular way. Most importantly, it was for devs first — code-first, local-first, and extensible. Instead of retrofitting a local dev story onto an existing cloud solution, we started with dev-time, and made it flexible enough to handle even the whackiest custom cloud environments. And thus we decided on what’s on the website today — “Streamline your development with .NET Aspire; Build, run, and test your full stack locally”.
