Invisible Architecture — Episode 2 - Projects Change. Naming Pain Doesn’t.
Why every product name is a constraint you choose, not a word you like.
This column is a build diary: it documents, step by step, what it means to take a product from zero to finish line, including mistakes and course corrections.
People think naming is a creative moment.
A brainstorm.
A list.
A winner.
They don’t see the real thing:
naming is where you discover what a project actually is.
Not in theory.
In reality.
Because the name isn’t describing the product.
It’s defining its borders.
And borders decide everything.
Hook
Over time, I’ve had multiple ideas.
Some evolved.
Some merged.
Some died quietly.
But the pain of naming is always the same:
you’re not choosing a “nice word.”
you’re choosing what the project is allowed to become.
And when you’re building alone, that choice weighs twice as much, because you’re not naming something finished. You’re naming a journey. With adjustments, mistakes, fixes, and restarts.
That’s also why this column exists: these projects are still in development, and documenting what it takes to carry them from start to finish is the most honest way to show how much “invisible architecture” sits behind every decision.
The Invisible Layer
Here’s the part nobody explains:
a name is a constraint selection.
It silently answers questions like:
Is this serious or playful?
Is it for students or for professionals?
Is it a tool or a lifestyle?
Can you imagine it on a landing page, in a pitch, in an App Store listing?
Can you say it out loud without having to explain yourself every time?
That’s why naming is exhausting.
Because it’s not just a label.
It’s a decision that demands coherence while you’re still building: UX, UI, code, copy, structure, and all the small choices a team would normally spread across multiple roles.
When projects are still in development, the name matters even more: it doesn’t have to “explain everything,” it has to hold the meaning together while the rest takes shape.
A Map Of What I’m Actually Building
1) Project Taloma
Project Taloma was never allowed to be “just a cool name.”
It needed to convey seriousness and safety.
Not in a cold or distant way, but in a trustworthy way: something that, when seen on a page or heard in a conversation, doesn’t feel like a trend or a toy.
Taloma lives close to a delicate world: families, educators, and children dealing with real difficulties.
So the name had to stay human, while keeping a tone that wouldn’t trigger ambiguity or light, casual associations.
There’s also a deeper layer: Taloma echoes “Talamo” (the thalamus), not as a scientific badge, but as an honest meaning layer.
The thalamus is a passage point: it connects, filters, routes. And in its core purpose, Taloma aims for something similar: helping create order, connection, and continuity where things are often fragmented.
At that stage, the criteria weren’t “find the perfect name.”
They were practical: sound, memorability, a level of neutrality (no weird connotations), and most of all a tone that matches the contexts where it will be said and read.
A name that holds up in a UI, when spoken out loud, and when written on a page.
Taloma taught me this:
some projects can’t afford “vibe.”
They need to communicate trust from the name, because before the product is complete, you’re already asking for confidence.
2) Project BaseLocker
Project BaseLocker was born from a different battlefield.
Not “high meaning.”
Plain reality.
Three days of searching.
Domains taken.
Names that looked fine, then collapsed the moment you actually tested them: written down, spoken out loud, imagined inside a UI, as an icon, as a headline.
Then the shift happened:
instead of naming features, I named a place.
Because “locker” isn’t startup language.
It’s human language.
A locker is a stable container. A personal place.
It doesn’t promise magic, it promises order, a base, continuity.
And “Base” adds the key idea: it’s not just any container, it’s a starting point and a return point. A place where study isn’t scattered across apps, notes, reminders, and mental noise, but actually “lives” somewhere.
This wasn’t poetry either. It was criteria.
It had to be pronounceable, memorable, neutral enough to speak to different students, and scalable enough to hold if the project grows.
And it needed to work in its usage context: when you say it, when you read it inside a UI, when you see it as a title.
BaseLocker taught me this:
place beats features.
Because place creates belonging. And belonging is often what makes people stay.
3) The “Invisible Projects” (the ones you don’t publish)
There’s a category most builders don’t talk about:
the projects you’re working on, but haven’t made public yet.
They’re real work.
They shape your skills.
They consume hours.
But they can’t be used as proof.
So I don’t present them as “projects.”
I treat them for what they are:
labs.
Internal R&D.
Experiments.
Systems in progress.
And this matters, because naming works differently here:
a public product name needs clarity and trust
a lab name only needs internal coherence
Different constraints.
Different responsibility.
Decision
So what’s the lesson?
A name is not branding.
A name is a boundary.
If you can’t name something, it often means you haven’t chosen the constraints yet.
And constraints are the invisible architecture of every product.
What Changed
I stopped treating naming like a “creative step.”
Now I treat it like this:
a name is a boundary
a boundary is strategy
strategy creates coherence across everything that comes next
App.
Website.
Tone.
Copy.
Features.
Positioning.
Naming is where coherence begins.
Next Step
Next episodes go deeper.
Not theory.
The real naming wars:
why Project Taloma forced trust over trend
why Project BaseLocker forced reality over imagination
how, in my way of seeing it (in the projects I build on my own, and again, this is just my perspective), naming often becomes the first “system decision”
Because the name is not a word.
It’s the first piece of architecture.
And most people never see it.
Quick Check (2 minutes)
If you want, reply in the comments with 3 short lines. No essay needed.
One-liner: describe your product in a single sentence (no buzzwords).
Constraint #1: what’s the one thing you cannot betray? (time, trust, simplicity, privacy, tone, etc.)
Stress test: does your project name hold up when you say it out loud, when you place it in an app header, and when you use it as a landing page headline? Be honest. No pressure. We’re all here to share, improve, and learn.