29 — Branding & Identity

The project’s name, mark, voice, and the policy around them. This document captures decisions made + open questions on identity. Most of this is unresolved and needs the founder’s input.

Status

The project’s name is currently “Locara” as a working placeholder. Domain, logo, and full brand identity are unresolved.

This doc structures the decisions; resolution happens before phase 0 closes (public posture).

What naming + branding has to do

The project’s identity must:

Be memorable. A developer should remember it after one tweet.
Be available. Domain registerable, npm/crate-name unclaimed, social handles available, no trademark conflicts.
Be unambiguous. Doesn’t clash with existing AI / dev-tools brands.
Be pronounceable. English-speakers can say it; doesn’t have problematic meanings in major languages.
Carry the values. Hints at “local,” “yours,” or “private” — but doesn’t have to be literal.
Scale. Works as a noun (“install Locara”), verb (“I built it on Locara”), domain (<name>.app), GitHub org (<name>).

Naming criteria checklist

Before locking in a name, run it through:

Naming candidates (placeholders)

These are not committed; they’re working options to compare:

Name	Pros	Cons
Locara	”Local” + soft suffix; unique-ish	Made-up; users may not remember
Atlas	Strong, evocative (“carries the weight”)	Heavily used; many conflicts
Cabin	Cozy, local, intimate	Twee for dev tools
Hearth	Local, warm, “where things live”	Twee; hard to verbalize
Stove	Practical, local, AI generates “heat”	Strange for software
Forge	Building, craft	Heavily used (Microsoft Forge, etc.)
Anvil	Shaping, crafting	Anvil already exists in Python tooling
Plexus	Network, connections	Too clinical
Atrium	Open, central	Too architectural
Loom	Weaving, craft, fabric	”loomdb” exists; weaver tools
Hearthstone	Local + warmth	Blizzard owns the trademark
Beacon	Light, signal	Many AI/data products use this
Lantern	Light, local, you-carry-it	Many products; not differentiated

Real naming exercise needed; this is just a starter set. Recommended approach: a small set of finalists → trademark + domain check → final choice.

Visual identity (placeholder)

To be designed. Initial direction:

Tone: quiet confidence. Not a tech-bro logo; more in the spirit of Obsidian, Tailscale, or Are.na.
Color palette: restrained. One signature color (deep, possibly violet or muted green) plus neutrals. Avoid AI-trope chrome / gradients.
Typography: modern serif + clean sans pairing. Hint of craft / longevity.
Mark: abstract / geometric, not literal. Avoid “house” or “vault” iconography (too direct); prefer something that suggests structure + locality.

Voice and tone

Brand voice

Calm. Not breathless about AI. Not panicky about privacy. We’re building software for adults.
Precise. When we make a claim (“fully local,” “no telemetry”), we mean it specifically and verifiably.
Plainspoken. No jargon when plain words exist. “Apps that run on your Mac” beats “on-device generative AI deployment platform.”
Warm but not folksy. We’re not your friend’s startup. We’re a project people choose to use.
Confident in scope. Locara is for narrow, opinionated apps. We don’t pretend to be everything.

Models for the voice

Steph Ango (Obsidian) — calm, craft-oriented, occasional personal essay. The strongest analogue.
Tailscale’s blog — technically deep, unhurried, founder-led.
Stripe’s docs — precise, friendly, never condescending.

Anti-models

OpenAI marketing tone — vague hype.
VC-funded launch tone — superlatives + “the future of X.”
Privacy-startup defensiveness — “we don’t sell your data, unlike them!” is reactive.

Examples

Good (target voice):

Locara is how you build apps that run on your Mac. No cloud. No accounts. No tracking. The data stays where you made it.

Bad (not target voice):

🚀 Introducing Locara — the future of on-device AI! Build powerful, privacy-first apps with our cutting-edge framework. Unlock unprecedented developer velocity in a world after the cloud. ✨

The bad version is what we never write.

Naming components within the brand

Once the parent brand is locked, sub-components inherit:

Component	Naming pattern
The CLI	`<name>` (lowercase, the binary)
TypeScript packages	`@<name>/sdk`, `@<name>/components`, etc.
Rust crates	`<name>-core`, `<name>-runtime`, etc.
The desktop client	`<Name>` (capitalized)
The runtime / shell	”Runtime” / “Shell” descriptors
App ID format	`<publisher>/<app-name>`
Domain	`<name>.app` (preferred), `<name>.io`, `<name>.dev`, fallback `<name>.com`

Brand usage policy (placeholder)

Once the project goes public + has a real legal entity, the brand is protected. Provisional rules:

Allowed without permission

Linking + mentioning. “I built this with [name].”
Factual references. “[name] is a framework for…”
Educational content. Tutorials, courses, blog posts, videos using the name as the subject.
Compatible products / extensions. “An [name]-compatible registry.”
Parody. Within reasonable limits.

Requires permission

Logo usage in commercial materials.
Hosted services using the name (e.g., “[name] hosting,” “[name] cloud”).
Commercial products with the name in the title (e.g., “[name] Pro” sold by a third party).
Domain names containing the brand (<name>-pro.com, etc.).
Forks materially diverging from the spec — must rename.

Never allowed

Impersonation. Pretending to be the project or its maintainers.
Misrepresenting compatibility. Selling a product as “[name]-compatible” when it isn’t.
Trademark infringement. Standard rules apply.

A formal trademark policy gets written when the legal entity is formed (phase 4+).

Domain strategy

Primary: <name>.app if available.
Backup: <name>.io, <name>.dev, <name>.com.
Defensive: register variations to prevent typosquatting (cost-effective if the name is short).
Subdomains: docs.<name>.app, cdn.<name>.app, blog.<name>.app.

Logo + mark (open)

To be designed. Approach:

Iterate small. A wordmark in the right typeface is enough for v0.
Professional design pass before phase 3 (registry public).
Open-source friendly. Source files (Figma / Illustrator) committed to the repo so contributors can use them.

Once the name is locked, register handles on:

GitHub (org).
X (account, even if rarely posted).
Mastodon / Bluesky (where the indie-tech audience lives).
LinkedIn (project page; useful for credibility, not marketing).
YouTube (eventually, for demos / talks; not v1).

Don’t use most of these. Just hold them.

Press / launch

When phase 3 ships (public registry):

Hacker News submit by the founder.
Indie Hackers post (Pieter Levels’ audience).
Product Hunt if appropriate.
Blog announcement with screenshots + 60-second demo video.
Selected outreach: technical bloggers / podcasters who cover this space (Simon Willison, Andrej Karpathy’s circle, etc.).

No paid launch. No press release. Word of mouth + earned attention.

Open questions (decisions needed)

(open) What is the project’s actual name? Resolution before phase 0 closes.
(open) Domain — .app, .io, .dev?
(open) Visual identity — DIY vs hire designer? For phase 0–1, DIY is fine; phase 3+, hire.
(open) Legal entity for trademark / project IP — sole proprietor, LLC, nonprofit (e.g., Open Collective fiscal host)? Affects governance + monetization. Probably depends on country of residence + tax considerations.
(open) Mascot? Many indie projects have one. Probably no — too cutesy for the calm voice.

Phasing

Phase 0: Lock name + domain. Wordmark in chosen typeface. Color palette. Voice guide (this section).
Phase 1: Logo polished. Brand usage on README, devlog.
Phase 2: Marketing site refines visual identity. Continued voice consistency.
Phase 3: Full visual system. Brand usage policy formalized.
Phase 4: Trademark registered (if pursued). Brand assets kit published.

Cross-references

Governance + brand legal aspects: 23-governance.md
Marketing site (uses brand): 12-registry.md, website folder
Manifesto (the public-facing pitch in brand voice): ../website/content/manifesto.md
Obsidian’s brand voice as a model: ../notes/obsidian.md
Tailscale’s brand voice: ../notes/tailscale.md