I’ve learned over the years that shipping fast compounds exponentially only if you’re also learning fast. Otherwise, you’re just pushing volume (and many mistakes) into production, celebrating the wrong kind of momentum.

This learning doesn’t come from dashboards, support tickets, or any of the other mechanisms we’ve developed as proxies for proximity to the people we’re building for. It comes from contact: watching someone use the thing you built, seeing how they react, and ensuring that directly informs what you do next. Having direct access to users means putting yourself in their shoes and seeing how the product feels. It’s about seeking the truth.

There’s also something different about building at this moment. The same forces that make it possible for anyone to describe software into existence mean that what people do with Dreamer is genuinely out of our hands, in the best possible way. We can ship the platform, but the community invents what it becomes through unexpected use cases, agents we’d never have thought to build, and combinations of tools that only make sense to the person who needed them. It’s also why community isn’t a function that sits alongside product at Dreamer — it’s just as foundational, and we treat it that way.

Here’s how we’re doing our best to operationalize that.

1. Be the User

One of the routines we practice religiously is friction logging, a tool I learned from my years at Stripe. Our entire team takes the time to sit down and document our own experience using our product, feeling where things feel slow, confusing, or broken. It forces the entire team to feel what users feel in a way that no amount of analytics can replicate. We also follow a practice of talking to users and understanding their needs before any design work begins.

These practices sound obvious until you realize how rarely they actually happen – it’s easy to deprioritize a few hours of walking in the user’s shoes when the week is already full, but those moments have a way of changing what you thought you knew about the product. I’ve never once come away from them without something worth acting on.

2. Actively find where your community shows up and talk to them

It’s this principle that shapes how we think about finding our community, both online and in person. The temptation early on is to reach for the engagement dashboard, but data at this stage is sometimes a way of feeling busy while avoiding the harder question of whether what you’ve built actually works for people. The only way to know is to go find out directly, repeatedly, and on their terms rather than yours.

Online, we go where builders already gather and try to be genuinely useful when we do. For instance, @swyx mentioned that Dreamer could help coordinate the AI Engineer World’s Fair he runs, so we built him an agent to show what was possible. It’s my favorite conference app, ever!

We also know that a lot of the best builders behind great MCP servers are doing it purely for the love of it, with little to sustain the habit — so we put $10K behind the best tool built in Dreamer by April 15th (Still open if you want to enter!).

In person events with strong, existing communities like @foundersysk have been invaluable. I shared our product at their January showcase before we’d announced Dreamer publicly, because the most valuable conversations happen before you’ve figured everything out, not after. The 300 curated engineers in that room were the first to see our product, our brand, our vision (and our bright purple swag) and the energy in the room that night reminded us why getting in front of the right builders early is worth every bit of effort it takes. Only eight weeks later, a few of them have even joined our team.

This instinct wasn’t strategic so much as it was obvious… if you’re going to build something that matters, you want to find the people who care most about the problem and get near them as fast as possible. The community we wanted to build and the team we wanted to build were never two separate projects.

3. Build with them, not for them

The third practice is really less about communication and more about a relationship. Every week, we share what we’ve been building, because that’s what you do when you’re creating something with people rather than for them. The most interesting suggestions about Dreamer’s future aren’t happening exclusively in our roadmap docs, but in our Discord and at our community events, between builders who are helping each other, surprising each other, and nudging us towards great features we’d never think of.

The only way Dreamer becomes what we believe it can be is if the community built on it creates more than we ever could alone. And the only way that happens is if people genuinely feel like contributors to the platform, and are inspired by the other builders around them.

The principle underneath all of all these practices is simple: get close, and stay close to your users.

The builders who’ve been with us from the beginning, through the messiest, most unfinished version of Dreamer’s alpha, have shaped what it is today in ways we could not have roadmapped. They’ve built agents that have delightfully surprised us and told us directly when something wasn’t good enough. That kind of feedback is a different category of useful, and it only comes from people who feel close enough to be honest. We’re lucky enough to have that from our early users, and are thankful for their trust.

This is also, not coincidentally, how the platform itself is designed. What one person builds, someone else can remix. What one builder discovers, the whole community benefits from. The best things that happen in Dreamer happen because people are building close to each other.

We (our team and community) are building in Dreamer. It’s a place you belong to, not just a product you download.

If you’re the kind of person who wants to be close to something while it’s still early and being figured out — build something on the platform (dreamer.com). Come join us in Discord. Publish something to the Gallery and see what happens when the community gets hold of it.