The Branding Journey: From a Functional Name to VORA

Naming looked easy until the product started growing.

We began with a functional name that described what the app did. That worked early on. But as the product expanded, the name started limiting how users understood the platform.

This post explains how we moved to VORA, what changed, and what we learned from the process.

📋 Phase 1: Purely Descriptive Naming

We started with "AI Conference Assistant." Literally. If you dug into the repository history, you'd find a folder called AI_conference_assistant — our original GitHub repo name before the rebrand.

That made sense during prototype stage:

• quick to choose
• clear to insiders (devs immediately understood "conference" meant business meetings)
• no branding overhead
• we were still figuring out the core use case

But here's the problem: a meeting could also be a podcast interview, a lecture recording, a customer call, or a therapy session. We were building something broader than just "conferences," and the name was a prison.

Descriptive names age poorly when scope expands. Users couldn't search for it. It wasn't memorable. It didn't sound like a product.

📋 Phase 2: Broader but Still Generic

We tried to fix it with a second pass: "Meeting Assistant."

Technically more accurate than "Conference Assistant," but now we had a new problem — the market was flooded with "AI Meeting" tools. There was no differentiation. When someone searched for "meeting assistant," we weren't even findable against established names.

It solved the first constraint, but still failed to create a distinct identity users could remember or search for easily. It was like naming your startup "Software Company" and hoping for the best.

🔑 Phase 3: Choosing VORA

We went through maybe 40+ candidate names. Most were forgettable. A few sounded like pharmaceutical brands. One sounded like a pasta sauce.

VORA won because it actually met practical constraints:

• Short and memorable — four letters, easy to type, easy to say out loud in meetings
• Globally pronounceable — it doesn't rely on English phonetics; works equally well in Korean, Japanese, European languages
• Works in Korean contexts — no weird transliteration issues; it sounds intentional in both languages
• Flexible for expansion — it doesn't lock us into "meeting" or "conference" or "voice"; it's abstract enough that we can add features (summaries, analysis, reporting, multi-user workflows) without the name feeling wrong
• Unique — searchable, defensible as a brand, not a common English word

After selecting the name, we systematically aligned:

• UI copy and button labels
• Page titles and navigation
• All metadata (SEO, social, schema markup)
• Internal code comments and variable names
• Support documentation and FAQ responses
• Error messages and onboarding text

Everything pointing to one consistent brand voice.

🧠 The Core Meaning: Voice + Oracle

The most important part of the name wasn't just how it sounded. It was what it meant.

Here's the technical definition we use publicly: VORA stands for "Voice Optimal Recognition Assistant" (you can see this on the About page).

But internally, we frame it differently: Voice + Oracle.

• Voice represents the raw source: real conversations, meeting audio, accents, interruptions, domain jargon, side comments, the messy reality of how humans actually communicate.
• Oracle represents interpretation: turning that noisy input into structured decisions, action items, and knowledge you can actually use.

That combination describes the product's actual job better than generic labels like "AI meeting tool" or "transcription software."

We're not trying to be just another recorder. We're trying to be the intermediary layer that helps teams understand what was actually said, what was decided, and what needs to happen next.

The workflow is:

1. Audio in — raw meeting recording
2. Signal extracted — accurate transcription
3. Decisions surfaced — AI identifies key topics, decisions, next steps
4. Follow-up clarified — output is structured and actionable

The "Oracle" framing is especially important because it positions VORA as a tool for judgment and clarity, not just transcription. A transcript tells you what was spoken. An oracle helps you understand what matters in that transcript — what affects your business, what needs action, what can be ignored.

This also gave us long-term brand flexibility. Even if features evolve (real-time summaries, QA workflows, multilingual post-processing, reporting dashboards, domain-aware analysis), the Voice + Oracle concept still holds. It's abstract enough to scale.

That's why this meaning became central both internally and externally: it's memorable, it's accurate, and it scales with the product roadmap as we add features.

⚠️ The Real Cost of Renaming

Renaming is not just visual replacement. It's genuinely tedious and touches way more surfaces than you'd expect.

We had to touch:

Domain & URL Structure

• Set up a fresh subdomain: vora.vibed-lab.com
• Migrated all pages: index.html, app.html, blog.html, faq.html, about.html, etc.
• Each page had to be duplicated for bilingual support: index.html + index_ko.html for English and Korean
• Set up proper hreflang tags for search engines to understand the language alternates
• Configured canonical URLs for each page variant (e.g., https://vora.vibed-lab.com/index.html)
• Added social preview metadata (OpenGraph tags) for all pages — that's where users see the product name when shared on Twitter/LinkedIn

Technical Metadata

• Updated page titles: from "AI Conference Assistant" to "VORA - Free AI Meeting Minutes & Business Insights"
• Rewrote all meta descriptions and keyword targeting
• Updated JSON-LD schema markup (the structured data Google uses for rich results)
• Fixed OG:image URLs, OG:site_name, and social card configurations across 40+ pages

Code & File Names

• Renamed HTML files (e.g., conference_assistant.html → app.html, though we didn't use the old name)
• Updated internal variable names in JavaScript (roughly 200+ find-and-replace operations)
• Changed API endpoint references in the frontend code
• Updated CSS class names and component IDs where they referenced the old brand

The Bilingual Complication

• Every page has a Korean twin (about.html + about_ko.html)
• That meant updating metadata, titles, and descriptions twice for each page
• The hreflang network had to connect both languages and both regions (en-US, ko-KR)
• Any changes to navigation or structure had to be mirrored

Even after what felt like a complete pass, legacy traces remained in:

• Old git commit messages still mention "conference assistant" (we didn't rewrite history)
• Some internal logging still used abbreviated codes from the old system
• Archived blog post snippets referenced the old naming

That's normal. The goal is consistency going forward, not perfect historical erasure. You ship the change and accept that archaeology will eventually find traces of the old name.

🎯 Brand Positioning Decision

We also made a positioning call: keep onboarding simple and remove unnecessary friction from the user experience.

That decision shaped both copy and product framing. Instead of abstract branding language ("Transform Your Communication" or whatever), we leaned into practical value:

• "Free AI Meeting Minutes & Business Insights"
• "Real-time speech recognition, automatic meeting analysis"
• "No sign-up required, no data stored"

Users can verify these claims in 30 seconds. That's the kind of copy that lives alongside the VORA name across landing pages, social previews, and docs.

🌍 Bilingual Branding Constraint

Because VORA serves both Korean and English users, we made a critical decision: use one shared brand token (VORA) across both language surfaces.

This avoids brand fragmentation. Users see "VORA" in English UI and Korean UI. It's consistent in:

• Page titles and headers
• Navigation labels
• Meta descriptions
• Social media previews
• Error messages and system copy

The UI text around VORA is translated (한국어 / English), but the product name itself stays singular. That keeps recognition consistent and avoids creating a Korean-only variant that feels disconnected from the English community.

It's a small decision with long-term implications for brand recognition in international markets.

💡 Takeaway

Name decisions are product decisions.

If you think your project might become a real product, treat naming with the same seriousness as architecture and domain setup. Don't skip it because "we can always rebrand later." You can rebrand later, technically. But the cleanup cost is always higher than expected — URLs, metadata, social previews, internal tooling, documentation, historical references.

Choose a name that:

• Can survive feature expansion
• Works across languages if you plan to go international
• Is unique enough to own on search and social
• Doesn't box you into a single use case

The technical work is just the beginning. The real value of a good name is that it lets people remember you, find you, and understand what you're building without having to hear the pitch twice.

2026.02.18