Case Study
Selora
A pronunciation tool that scores your voice syllable by syllable. I designed it, built it with AI and put it online on my own. It is not a prototype, it is a product in production: from an empty Figma file to a live MVP in under a week.
- Category
- EdTech
- Role
- Product, UX & Code
- Scope
- Responsive web · SEO
- Status
- Live in production
- Person, end to end
- 1
- Figma to live MVP
- < 1 week
- Hand-picked word pages
- 65
- Per six-word test
- ~1¢
Short on time?30 sec summary
The problem. If you speak Spanish, finding out how an English word actually sounds is surprisingly hard. The dictionaries that rank on Google are written in English, for English speakers: notation you can’t read, no translation, and no way to know whether you said it right.
The bet. Rank for the long, specific searches Spanish speakers actually type, like “cómo se pronuncia worcestershire en inglés”, and answer it with translation, CEFR level and scoring of your own voice, which almost nobody offers.
What I built. Search, phonetics, and a recorder that scores you syllable by syllable, on an SEO surface built to rank. I designed it and built it with Claude Code: a designer taking a real product all the way to production, not a demo that never leaves a prototype link.
The reframe. Finding a near-identical competitor mid-build did not kill the project, it made the strategy clearer: words bring people in, sentences are what people pay for.
Where it stands. Live at getselora.com, with a mirror product for English speakers learning Spanish on the same engine and features still landing. The metric I don’t have yet is the important one: how many visitors press record.
Challenge
If you speak Spanish, finding out how an English word actually sounds is surprisingly hard. The dictionaries that rank on Google are written in English, for English speakers, with phonetic notation you can’t read and no translation in sight. And none of them tell you whether you said it right: you get audio to copy, but no feedback on your attempt.
- How do you say worcestershire?Where does the stress go?What does it mean?Does it sound different in the UK?Which vowel is that, exactly?
- Is it skéd-jool or shéd-yool?Did I say it right?What level is this word?How do I read /ˈkiːbɔːd/?Am I close, or way off?
The product challenge was clear. The harder one was personal. I come from product and UX, not engineering, and I wanted to build and ship the whole thing myself: search, phonetics, a recorder that scores your voice syllable by syllable, and an SEO surface that could rank. No team, and no backend developer to hand the hard parts to. Every decision was mine to design and to implement.
Positioning & validation
The thesis was a search bet: rank for the long, specific searches Spanish speakers actually type, like “cómo se pronuncia worcestershire en inglés.” Those results are owned today by English-language dictionaries. Selora’s edge is that it is built for Spanish speakers, with the translation and the CEFR level up front, plus interactive scoring that almost nobody offers.
Mid-build I found a near-identical competitor. Instead of a threat, it sharpened the strategy: word practice is what brings people in from search; sentence practice, which unlocks rhythm and fluency scores, is what people would pay for. Words get you found. Sentences are the product worth paying for. Instead of guessing, I checked that funnel against examples from other industries, like a level test, which brings in far more people than a free download.
Design & build decisions
Being the only person on the project meant design and feasibility stopped being two conversations. Every UX decision was also a decision I had to build.
The whole MVP (search, phonetics, voice scoring and the SEO surface) went from an empty Figma file to production in under a week, designed by me and built with Claude Code. That speed matters for one reason: it moves the bottleneck. When building something takes hours instead of sprints, the expensive part is deciding what to build. That is where a designer should spend the time. Everything below is a decision that survived that filter.
The product is two paths, not one. A content path that Google can reach: a word page rendered on the server, with the transcription, the translation and the syllables. And a practice path that scores you: your recording is encoded, sent to be assessed, and comes back as a traffic light for each syllable. Every decision in this section belongs to one of the two.
![How Selora works, on Next.js 15 with SSR and external voice APIs. Content path, server-side: a long-tail Google search reaches the server-rendered, indexable /pronunciar/[word] route, which builds the word page (word, IPA and syllables) from curated data plus a dictionary. Practice path, client plus Azure: the recorder encodes the take to WAV, posts it to the /api/assess route, Azure Assessment returns a per-syllable score, and the app turns it into a green, amber or red traffic light at a threshold of 85](/work/selora/03-how-it-works.png)
What the AI actually did, and what it got wrong
Claude Code wrote almost every line. That is not special any more, and on its own it proves nothing. The real work is the distance between a demo and a product.
What it did not do was decide. It did not know that Azure’s SDK was broken on this Node version, that the syllable splitter was wrong on twenty of the sixty-five words, or that the score it returned was too kind to everyone who tried. Each of those looked like working code and was a bad product. Catching them is my job. It is the same job as deciding when a green light is deserved, or noticing that a refresh button moves under the cursor.
What proves this is a product and not a prototype are the boring parts. It costs about a cent per test. It stays useful when the paid services are gone. It controls its own indexing. And the sixty-five word pages are checked by hand, not whatever an API returned.
Design system: tokens straight from Figma
The visual system lives as theme tokens in the stylesheet, sourced from the Figma file. No component ever hard-codes a hex value. Design and code share one source of truth, so a change in the system propagates everywhere. The Figma file isn’t a mockup I hand off, it’s the origin of the running app’s tokens.
Scoring by REST, not the SDK
Azure’s Speech SDK runs on a WebSocket over HTTP/2 and throws error 1006 on recent Node versions. I moved to the plain REST API, which is plain HTTPS and works everywhere, and found the score payload arrives flat, not nested the way the docs suggest. The kind of thing you only learn by building it, not by reading about it.
The model was too generous
The first version gave almost everyone a high score. That is a problem: if a careless attempt comes back green, the tool is a toy. The number I was showing was a combined number: accuracy, fluency and completeness averaged together. On a single word, fluency and completeness are near-perfect no matter how you say it, so they pushed every score up.
The fix was not technical, it was about what to show: show accuracy on its own, and raise the bar of the syllable traffic light so green has to be earned. Designing with a model is mostly deciding what part of its output the person actually sees. The API gives you data, not an answer. Choosing which number is the honest one is a product decision.
Syllable splitting is data, not an algorithm
A splitter that only reads spelling cannot see how a word is really put together, so it broke on more than twenty words (“pas-sport”, “dow-nload”, “sof-tware”). Since the word list is short and checked by hand, I wrote the divisions by hand and kept the automatic rule only as a backup for whatever someone types into the search box. Sometimes the right answer is not to build an engine at all.
The canonical URL is an env var, and it controls indexing
One variable resolves the canonical domain, and when it’s unset the pages emit a noindex tag and the sitemap is withheld. Deliberate: it stops Google from indexing temporary preview URLs that would compete with the real site. A one-variable decision with real SEO consequences.
Graceful without the paid services
Pull the speech keys and the site still works: search, reference audio and phonetics stay live; only scoring shows a “not configured” notice. The product stays useful instead of breaking.
The small stuff, on purpose
The refresh button sits before the row of words, not after it: it gets pressed repeatedly, and afterwards the row changes length and the button slides out from under the cursor. Header flags were removed, because a language isn’t a country, and the US/UK accent toggle uses SVGs, not emoji, because flag emoji render differently on every platform. The segmented control uses grid, not flex, so the label lines up with the centre of the pill. Nobody notices any of this when it is right.
Results
Selora is live in production and does the one thing dictionaries don’t: it scores your voice, syllable by syllable, with a Spanish-first framing. The unit economics hold up, at roughly a cent per six-word test, and a former English teacher started promoting it organically on LinkedIn, which became the first real traffic and a warm lead for a teacher-driven distribution channel.
The engine works the same in both directions, so there is now a mirror product for English speakers learning Spanish: the same scoring, the same page structure, the long tail flipped. One build, two markets, and the second one cost almost nothing to open.
Selora isn’t finished, and the case shouldn’t pretend it is: it’s an evolving product with features still landing, sentence practice being the next big one. The metric I don’t have yet is the important one: what share of visitors who come to hear a word actually press record. Someone Googling “how to pronounce schedule” wants an answer in five seconds; recording and practising is a different intent. Measuring that is what should decide where the product goes next. Saying what I do not know yet is part of the job.
Learnings
Judging a human voice takes human judgment.
The scoring API was happy to tell everyone they had done great: the combined score it returns is near-perfect on a single word, and only sitting with real attempts made that obvious. The more human the thing being judged (a voice, an accent, someone’s effort), the less a model’s raw output can stand as the answer. Deciding which number is honest, and what a green light is allowed to mean, is still a call a person has to make.
Shipping surfaces the questions research can’t.
Building the whole thing end to end is what exposed the real question: do people actually want to record themselves? No amount of upfront planning would have found it as sharply as a working product did.
A designer who builds makes different decisions.
Plenty of people build things with AI now. Fewer take one all the way into production, and fewer still do it from the design side. Owning both the Figma tokens and the running code collapsed “is this feasible?” and “is this good UX?” into one call: the REST-versus-SDK fix, the hand-written syllables, the indexing env var. Those are product decisions that only exist because I was the one implementing them.
Positioning beats features, and a competitor can be a gift.
Finding a near-identical competitor mid-build didn’t sink the project; it clarified it. Words became the acquisition layer, sentences the paid mechanic. The sharpest strategic move came from an outside signal, not from adding more to the product.
