When I started building BitVoices, I knew why I wanted it to exist before I knew exactly what it needed to be. The idea grew naturally out of the mission behind NotableBIT: amplifying Black excellence in tech. I wanted Black technologists to have a place where we could be visible, share what we were building, celebrate achievements, publish articles, make connections and see more of ourselves represented in technology.
At the time, my mental model for an online community was pretty straightforward. A social platform seemed like the natural way to create that space, so the first version of BitVoices took shape around profiles, posts, comments, reactions, follows, notifications, videos, news and a feed. It looked like a social network because that's what I understood an online community platform to be at the time. What I didn't understand yet was that building the software would become part of discovering what the software was supposed to be.
When the software doesn't feel right
The more I built BitVoices, the more it started to feel like everything else. One of the things that really started bothering me was the news feed. I found myself spending time every day curating articles about Black people in technology so there would be fresh content on the platform, but almost nobody was reading them and, realistically, they probably weren't going to. I could continue finding more content and adding more features, but neither answered the question that had started bothering me: What is BitVoices actually supposed to be?
I started asking more fundamental questions. Why am I building this? What am I expecting builders to actually do when they get here? What should they get from being here? What should happen because BitVoices exists that wouldn't otherwise happen?
I spoke with people about it. Low Key, my ChatGPT agent, and I had many conversations about it. I also started looking at other modern platforms to understand what they were doing and how they were thinking about community. I wasn't necessarily looking for features to copy. I was trying to understand what fit what I was building and, probably more importantly, what didn't.
As I got clearer about the purpose, I started seeing possibilities that weren't obvious when I was thinking primarily about building a social network. The question was becoming less about what content should be in the feed and more about what a builder should be able to accomplish by being part of BitVoices. That distinction changed the software.
The product changed as my understanding changed
Builder HQ began shifting the center of BitVoices away from the feed and toward the builder. I had started moving away from the "feed-first" assumptions behind the original platform and thinking about a different set of questions. Instead of primarily thinking about what someone wants to post or consume, I was thinking about what they're building, what they need, what they can offer another builder, what needs their attention and who in the network might be able to help them.
I was also thinking more deeply about what community could actually mean in this context. What could builders offer each other beyond reading and reacting to one another's posts? What relationships could form because two people found each other here? Could builders with complementary skills decide to work together on something? Could a team form? Could a company eventually come out of a relationship that started because two builders met on BitVoices? I didn't know what would happen, and I still don't, but those possibilities were much closer to what I wanted the platform to enable.
The original social features didn't need to disappear. Posts, comments, reactions, articles and connections still serve a purpose. What changed was my understanding of their role. They were no longer the organizing idea behind the product. The network itself, and the relationships that could develop within it, had become much more important.
That also changed how I thought about Hubs. Builders don't only need a network of people. Sometimes they need a place to gather around a particular interest, technology, business model or geography. That thinking eventually led to Hubs such as AI Builders, SaaS Builders and Tulsa Builders.
Even there, the discovery continued. The interesting problem wasn't simply how to add groups to the platform. It was understanding what gives builders a reason to participate once they're there. That has led me to think about things like prompts and Hub Check-ins that can create rhythm, accountability and collaboration without turning every community into a formal program.
Somewhere through this process I arrived at a phrase that now influences how I think about BitVoices: Community is culture, not features. That's different from saying features don't matter. Obviously they do. I'm still building software. But I can build profiles, feeds, messaging, reactions, groups and every other feature we associate with online communities and still not create a community worth participating in. The features have to support the culture, relationships and purpose of the community rather than becoming substitutes for them.
I was listening to the software
Months later, I finally found language for what had been happening. I had been listening to the software. I don't mean that in some mystical sense where the application suddenly developed an opinion about its product roadmap. 😂 I mean that the process of building, operating and observing the software was producing information that I didn't have when I started.
The news nobody was reading was information. My frustration with spending time curating it was information. Conversations with people were information. Watching how the platform was being used was information. Even the fact that I kept returning to the same questions about BitVoices' purpose was information.
Building in public amplified that process because BitVoices was publicly live in both forms. People saw the earlier feed-centered social platform, and they've been able to watch it change as my understanding of the product has changed. I've been talking about what I'm building while simultaneously building and operating it. I didn't disappear for a year, figure everything out and then unveil the answer. I was discovering BitVoices while BitVoices was already alive. That's what I've started thinking about as software discovery.
We usually put discovery before implementation. We gather requirements, understand the problem, make architectural and product decisions, and then build the software. I still believe that work matters. Software discovery isn't an argument for skipping it and figuring everything out while you're coding. It's an acknowledgement that discovery doesn't necessarily stop when construction begins.
Once an idea becomes working software, you can interact with assumptions that previously existed only in your head, a document or a mockup. You can operate the thing. Other people can use it. You can see where you're spending effort that isn't producing value. You can notice where the software technically works but somehow doesn't fit the purpose you thought you understood.
The implementation itself becomes another source of information. That's what happened with BitVoices. I didn't discover that the original social features were bad ideas. BitVoices still has a feed, profiles, posts, articles, comments, reactions and many of the things I started building in the beginning. I discovered that I had mistaken some of the mechanisms of an online community for the community itself.
I'm still discovering what BitVoices is becoming. The difference is that now I recognize discovery as part of building it. Requirements, conversations and research can tell me a lot about what software should be, but sometimes I also need to build enough of it to hear what the software has to say.
