Why we built Glossem
Every product is mostly words. Button labels, error messages, onboarding text, dialog confirmations, the empty-state copy that nobody else thinks about. Whether someone understands your product the first time they open it usually comes down to those words.
The problem is the words live inside code.
They sit in JSX files, string constants, database seeds, maybe a translation file if your team got religion about i18n. When a designer wants to rework the onboarding tone, or a writer wants to tighten a batch of error messages so they actually say what went wrong, the work has to go through an engineer. Engineers have other things to do. The copy work sits.
We kept hitting this wall on our own products. The shape of the problem was always the same. A non-engineer with strong opinions about the words. An engineering team that could not get to it for three sprints. Strings collected by hand into a Google Doc, edited there, then re-implemented manually back in code. Slow, error-prone, and demoralizing for everyone.
So we built the thing we kept needing. Glossem scans the repo, finds every user-facing string, presents them in a clean editing interface, and turns the changes back into pull requests. Review still happens in code. The actual writing does not require code.
Static analysis, not AI. We tried adding suggestions for unclear strings early on, and removed it within weeks because the suggestions were sometimes worse than the original. The right person to write your product's copy is somebody on your team. Glossem just gets the strings out of their way.
Related project
Glossem
All your product copy, in one place.
Other notes
The decisions that don't iterate
Most things you build are reversible. A few are not. Telling them apart is harder than it sounds, and getting it wrong is what most software regret turns out to be.
What 'honest software' means in practice
We use the phrase a lot. It is easy to say. It is harder to specify.
Why we built Vyzrly
College admissions has always been a black box. We wanted to make it a little more honest.
When AI is the wrong tool
The reflex to reach for AI on every problem is a symptom of taste failure, not technical sophistication.
Why we built USACO Tutor
Competitive programming builds a kind of thinking that matters. We wanted to make that more accessible.
Why we built Break the Test
The SAT has seven versions in circulation. Serious students burn through them in a month. The bigger problem is that even unlimited practice would not fix the thing that actually costs them points.