Every brand ends up with a voice whether it plans one or not. Ours grew out of a hundred small decisions made by different people at different times, which meant a support email could sound nothing like a tweet, and a tweet could sound nothing like the homepage. Nobody was doing anything wrong. There was just no shared answer to a simple question. When should ibbe sound confident and clean, and when should it sound like a person cracking a joke. We finally sat down and wrote the answer out.
The result is a document we are calling the ibbe brand language. It splits our voice into two registers instead of one flat tone. The first register is precise and confident, almost stripped of personality on purpose, and it is reserved for the moments where ibbe is stating what it built. A product announcement, an investor update, a release note headline. These moments do better when the sentence stands on its own without a joke propping it up. The second register is the one most people already associate with us, the blunt and slightly mean friend who talks straight to you instead of reading from a script. That register runs the tweets, the emails, the in-app messages, and most of the small moments where the product is actually talking to a person in real time.
What made this harder than picking two tones was figuring out where each one belongs, since almost nothing on the site is purely one or the other. A blog post like this one leans mostly toward the clean, confident register with only a little personality let in around the edges. A changelog splits closer to the middle, factual in the bullets and a little sharper in the header above them. A landing page runs both registers side by side on purpose, a plain and confident headline followed immediately by a subhead that talks like a person. We ended up building a full table mapping every type of writing on ibbe to a specific blend, because guessing case by case was exactly the problem we were trying to solve.
The document also settles a question that used to trip people up constantly, which is what happens when a joke and a real consequence collide. Our error states and empty states are almost entirely playful, since a broken button or a slow connection is a low stakes moment and deserves a laugh instead of an apology. But the moment a message involves losing data or a failed payment, the voice drops the joke completely and switches into plain, exact language. A delete confirmation should never sound like a bit. Knowing exactly where that line sits, in writing, means nobody on the team has to make that call from scratch every time.
We are sharing this publicly for the same reason we publish most of what happens inside ibbe. If you read our copy and it sounds consistent from a tweet to a launch page to an error message, that consistency came from a document, not a coincidence. And if you ever catch us breaking our own rules, you now know exactly which rule we broke.
