Brand Is a Container

MemeScanr is a product. Afia Labs is a brand. The difference matters more than most builders realize.

MemeScanr could fail tomorrow and Afia Labs would still exist. That is what I mean when I say a brand is a container. The product is one thing inside it. The brand is the thing that can hold the product, the next product, the book, the workbook, the course, the newsletter, the ideas that have not arrived yet, and the trust that connects all of them.

MemeScanr is the first thing I built inside that container. It will not be the last.

If I had understood this on day one, I would have made several decisions differently. I would not have registered my Apple Developer account as an individual under my personal name. I would not have tied MemeScanr’s earliest social presence so closely to me personally. I would not have treated the brand as something to figure out later.

Every one of those choices felt small at the time.

Every one of them became friction later.

That is part of why I want to write this chapter. Not because brand is decorative. Not because you need a logo before you need a product. But because once the work starts becoming real, the container starts mattering.

Your Brand Is a Container, Not a Constraint

A lot of solo builders avoid building a brand because they think a brand is a constraint.

They think naming a company means locking themselves into one thing forever. One category. One audience. One style. One future. So they avoid the decision. They avoid the name. They avoid the brand. They just ship “an app.”

I think that is backwards.

A brand is not a constraint. A brand is the opposite. A brand is a container that lets you build multiple things and connect them to each other over time. Without a brand, every product you make is an island. With a brand, each new product can borrow trust from the one that came before it.

That is what Afia Labs is for me.

It can hold:

• MemeScanr, the cleanup app
• This book
• The workbook
• The course
• Another product I have not thought of yet

Those things are not random. They are related because they live inside the same container. Someone who trusts Afia Labs through MemeScanr may be more open to reading this book. Someone who trusts Afia Labs through this book may be more open to using the next product. The trust compounds.

When you build your first product under a brand name, you are not just building one product. You are building a trust account that future products can borrow from.

Domain Before Code

Here is the smallest, cheapest thing you can do today that may save you from a ridiculous amount of regret later:

Register the domain before you write the first line of code.

I mean before the logo. Before the landing page. Before the polished brand strategy. Before you are “ready.”

Just own the name.

It usually costs very little. It takes a few minutes. The domain does not need to point anywhere yet. You do not need a full website. You do not need to know exactly what the brand will become. You just need to make sure the name is yours.

Because brand-name regret is one of the most annoying and expensive kinds of regret in consumer software.

If you build something under a temporary name and later realize you want to change it, the cost is not just technical. It is emotional. It is operational. It is discoverability. It is screenshots, links, accounts, SEO, search results, app-store listings, user memory, and your own sense of coherence.

MemeScanr.com cost almost nothing on the day I bought it. AfiaLabs.com cost almost nothing too. Those were some of the best low-cost decisions I made.

Small decision. Long shadow.

Case Study — The Developer Name That Would Not Change

The most instructive brand mistake I made with MemeScanr was not visual. It was structural.

When I signed up for the Apple Developer Program, I registered as an individual using my personal name: Bridgette Owusu.

At the time, that felt practical. I was one person. I did not have an LLC yet. I did not fully think of myself as a company. I wanted to move fast. The organization route required more setup, more verification, more waiting. The individual path was quicker, so I took it.

That decision followed me much longer than I expected.

Later, after I formed Afia Labs LLC, I tried to update the developer display name in App Store Connect so the app would reflect the brand I was actually building. That is when I learned something I wish someone had told me plainly:

Once you register as an individual, your developer display name is effectively tied to your legal name.

Yes, some information can be updated. The seller name on the information page can reflect the LLC. I did that. So MemeScanr’s seller now says Afia Labs LLC.

But the developer name that appears next to the app in search results, in the product-page header, and in places where people actually notice it still says Bridgette Owusu.

So now the product page carries two identities:

• Seller: Afia Labs LLC
• Developer: Bridgette Owusu

Neither is false. But together, they create brand friction.

It looks slightly inconsistent because it is slightly inconsistent. And when you are trying to build a container people can trust and recognize, inconsistency costs more than people think.

I have asked Apple about it more than once. The answer is always some version of, “we’ll look into it.” Nothing has meaningfully changed.

If I had registered as an organization from day one, I would not be carrying that friction now.

So here is the lesson as clearly as I can say it:

If you think there is even a decent chance you will build under a brand name, register your Apple Developer account as an organization from day one.

Do not tell yourself you will clean it up later. Do not assume the individual path is easy to reverse. Do not confuse speed now with simplicity later.

Some decisions feel administrative when you make them. Then they become brand architecture.

This is one of those.

Voice Is a Design System

A lot of people think brand means logo, colors, type, maybe a nice landing page.

That matters. But voice matters more than most builders realize.

Voice is what turns a product from “functional” into “memorable.”

MemeScanr has a voice. It is lowercase in-app. Playful. Slightly tired. A little Gen Z. A little self-aware. A little roasty. The app sounds like it knows what kind of mess your camera roll is, but it is not judging you for it.

That voice shows up everywhere: onboarding, empty states, error messages, notifications, paywall copy, button labels, celebration screens.

The onboarding says things like, “let’s see how cursed your camera roll is.”

The empty states say things like, “no duplicates. suspicious. are you ok?”

The paywall says things like, “you’ve earned the upgrade. here’s the one with the cool features.”

Those are not just cute lines. That is the product experience. That is part of why users remember MemeScanr. That is part of why they screenshot it. That is part of why it does not feel like the other four hundred cleanup apps that all sound like a filing cabinet.

Voice is not decoration. Voice is not frosting. Voice is part of the interface.

If you do nothing else for your brand, build a voice system.

Here is the simplest version.

Step 1: Pick three words that describe the feeling of the voice. Not three features. Three feelings.

Mine are: seen, playful, relieved.

Step 2: Write three phrases your product would say and three it would never say.

MemeScanr would say:

• “your phone called. it wants closure.”
• “4.7 GB freed. you’re welcome.”
• “scan your gallery to unlock your Wrapped”

MemeScanr would never say:

• “Congratulations on your successful scan!”
• “Click here to upgrade to Premium now!”
• “Improve your storage efficiency with one simple tool”

That difference matters. The second list is technically fine. It is also lifeless.

Step 3: Write every user-facing string through that voice lens. Every notification. Every empty state. Every error. Every onboarding card. Every paywall line.

Yes, it is work. It is also one of the highest-leverage branding moves you can make because users experience your voice far more often than they experience your logo.

Bigger Brand Thinking

One of the smartest things you can do as a solo builder is think bigger than one app.

Not bigger in the performative, empire-building way. Bigger in the structural way.

Build under a brand. Build a body of work. Build something that can hold multiple assets over time.

That is what makes a name like Afia Labs useful. It is not just a label. It is a home for multiple things: products, tools, books, learning resources, community, future experiments.

When you build under that kind of container, each thing can strengthen the others. One app can introduce people to your world. A book can deepen trust. A newsletter can keep the relationship alive. A course can teach what the products demonstrate. A second app can benefit from the audience the first one earned.

At that point, you stop thinking like someone launching random projects.

You start thinking like someone building a portfolio of assets.

That shift matters.

Because products can become sellable. Audiences can become reusable. Content can become discoverable. Systems can become repeatable. Trust can compound.

That is the long game.

The real goal is not just to ship one app. The real goal is to become the kind of builder who can ship again, learn faster each time, and create things that keep building on each other.

A bigger brand also protects you emotionally.

If one product struggles, it does not have to feel like your whole future collapsed. It becomes one product. One experiment. One asset. One chapter inside a larger story.

That is stabilizing. And stability gives you courage.

The Part I Wish I Knew Earlier

If I could go back and tell earlier-me one thing, it would be this:

Do not wait until the product is working to start thinking like a company.

You do not have to pretend to be bigger than you are. You do not need fake polish. You do not need startup theater.

But you do need to think about what you are building around the product, not just inside it.

What name will hold this? Who owns the domain? What will the developer name say? What voice will people remember? If this product works, what else could live beside it?

Those questions are not distractions from the product.

They are part of the product becoming real.

> Think Before You Move On

If your current product succeeded beyond your expectations, what would need to exist around it to support that success — brand name, domain, developer account, voice, website, email, audience? Which of those are you still treating like “later”?