William Imoh Built a Norwegian Tutor That Refuses to Speak English

William Imoh asked his Norwegian tutor to speak English. It refused. He asked again. It refused again, corrected his grammar, and carried on in Norwegian.

That was the product working exactly as intended.

After moving from Dubai to Norway, William discovered a frustrating kindness: when he struggled in Norwegian, people switched to English. A 1,000-day Duolingo streak hadn’t given him the conversational practice he needed. He wanted something patient enough to hear his mistakes and stubborn enough to make him work through them.

So he built Mural, a voice-first language practice app, using Codex to write native Swift and Kotlin. He had never written Swift, but he wasn’t starting from zero: he had five or six years of web development experience and four years as a product manager. That distinction matters. AI supplied implementation capacity; William supplied the problem, the desired experience, and the judgment to reject an inadequate result.

The same division of labor runs through his business. As founder and CEO of Hackmamba, a developer growth agency with around twenty-five people internally, he uses projects, routines, and role-based agents to handle operational work. Some of that setup is worth copying immediately. His permission settings deserve considerably more caution.

The tutor’s most important feature is its refusal

William’s first attempt at the app failed. At a hackathon in San Francisco, he built an earlier version that, in his assessment, delivered a poor experience. “Bombed the hackathon,” he said. “I think I probably came in last with it.”

The problem was real; the experience wasn’t there yet. He credits the realtime voice technology he later used with making the current version possible.

His requirement was more specific than “help me learn Norwegian.” He wanted to speak to something that wouldn’t judge him, would correct him, and would recreate the feeling of being dropped into a Norwegian village where English wasn’t an escape route.

The live demonstration made that requirement visible. William said he was in a meeting and used the wrong form of the word for “meeting.” Mural corrected him to “et møte” and asked what was happening in the meeting. When he requested English, it stayed in Norwegian and continued asking about the conversation.

The correction didn’t send him into a separate lesson. It happened inside the exchange he was already trying to have.

William originally wanted very little interface: speech and a caption. The caption gave a beginner a way to understand what they were hearing. Since then, he has added vocabulary tracking, flashcards, and conversation themes. He also described choosing a topic that prompts an internet search and becomes material for a conversation. But his center of gravity remains the Talk screen: open it and speak.

The lesson is in the constraint. A generally accommodating assistant might switch languages when asked. William needed the opposite. For anyone adapting this idea to tutoring, the question is: what should the tutor insist on, even when the learner asks for an easier path?

That is a design recommendation, not a claim that the episode established Mural’s effectiveness as a language curriculum. We saw a short conversation, an immediate correction, and resistance to switching languages. William reported that it helped his practice; the episode did not measure learning gains.

Codex could write Swift. William still had to describe the app.

William chose Swift for iOS and Kotlin for Android because he wanted a native experience and access to the platforms’ features. His own language familiarity was no longer the deciding constraint: Codex would write the implementation.

But his kickoff wasn’t a vague request followed by a finished application. He brought an understanding of front ends, back ends, architecture, epics, and user stories. He described the experience he wanted in a long initial prompt.

It opened with: “I want a very aesthetically pleasing application.” On its own, that would be thin direction. The useful parts came after it:

• A pulsating orb that he could talk to, with the familiarity of a phone call.
• A warm palette that felt like fall.
• A minimalist interface where no element existed unless it needed to.
• A request to follow design best practices “like you’re a senior designer at Apple.”

He also specified the voice technology. In the conversation, he calls it “GPT Live One,” and Claire later refers to “GPT Live,” describing OpenAI’s realtime voice model and its responsiveness to interruptions. Those are the names used in the episode, rather than a verified API configuration readers can paste into an implementation.

The first design still missed.

“The first design it produced was shit,” William said. It was in dark mode, which wasn’t the warm experience he wanted. He then made the feedback more concrete: use light mode, light warm colors, gradients, and liquid glass.

This is where the human work becomes easy to underestimate. “Make it beautiful” didn’t settle the design. William had to recognize the mismatch and name the changes that would resolve it.

Claire’s advice was practical: practice describing websites and apps. Explain what distinguishes one brand from another, what makes an interface feel minimal, or why one screen works better than another. Design vocabulary gives an agent something more actionable than approval or disappointment.

Want to try this? Start your brief with:

• The person using the app and the problem it should solve.
• The central interaction and the elements the user should see.
• Visual references, the desired feel, and anything to avoid.

That’s an adaptation, not William’s complete prompt. His process was to describe the experience, inspect the result, and get more specific about what needed to change.

The takeaway is narrower—and more useful—than “you don’t need to know how to code.” William could direct software work even when he couldn’t write its implementation language. His product and engineering experience still mattered.

Realtime practice has a real token bill

Mural solves an availability problem as well as a practice problem. William can start a conversation when he wants one, without arranging a lesson or worrying about embarrassing himself.

That convenience has a cost. He estimated roughly $3–5 for thirty minutes of conversation. He had put $1,000 into his OpenAI budget for people to use the app and said about $100 remained at the time of recording. He also made it open source so others could run it; the episode links to the Mural repository.

Those numbers describe his experience, not a universal price for building a voice tutor. The episode did not break down model settings, usage patterns, or infrastructure costs.

Claire’s comparison was with a one-on-one tutor: a voice session can cost less and be available in the middle of the night. That is a reasonable way to frame William’s personal spending. It is not yet evidence for a sustainable consumer subscription.

What is worth copying is the clarity of the tradeoff. William built something he wanted to use and was willing to fund. He initially resisted turning it into another business because he didn’t want the maintenance burden or user expectations. A successful personal tool doesn’t automatically need a business model.

Projects organize the work; agents go find the context

William’s operational setup started with an inventory, not a collection of bot personalities.

While planning Q3, he set an internal “100X” mandate: pursue much larger revenue goals without drastically increasing headcount. He explicitly wanted more AI use without handing the company’s creative work over to content-generation tools.

He listed his responsibilities in Notion: customer success, inbound sales, product, accounting, HR, interviews, and hiring. He was managing roughly eleven to fifteen deals in parallel. After an attempted chief-of-staff hire fell through, he leaned further into agents.

In his ChatGPT/Codex setup, he uses separate projects for operational areas and initiatives: Hackmamba operations, growth, sales, the website, his podcast, and the internal growth tool Boki. He also uses routines, including a Sunday-night operator brief asking what to start, stop, and keep doing, plus the three highest-impact activities for the coming week.

That’s a pattern worth borrowing: give recurring responsibilities their own context and ask for a decision-oriented brief, rather than a generic summary of everything that happened.

His role-based agents add another layer. He calls them his fellowship:

• Gandalf serves as chief of staff and was asked to create the other agents.
• Elrond handles engineering; Legolas handles marketing.
• Gimli handles accounts; Aragon handles sales and recruiting.
• Sam handles customer success; Frodo is the product owner.

Claire suggested adding an Eye of Sauron to watch across the system for problems. That was her proposed addition, not an agent William demonstrated having deployed.

The names are memorable, but the operational distinction is context retrieval. William described telling an agent, “Hey, I just spoke to this person. Get them into Three Pipes,” his internal people and HR tool. The agent then searches email, calendar, and meeting notes, adds the candidate to the system, and returns a summary. He said it also scores candidates and ranks them against others he has interviewed.

This was a described workflow, not a live end-to-end recruiting demonstration. The exact scoring criteria were not shown. The administrative part is straightforward to value; the ranking needs human scrutiny. A numerical position can look authoritative without revealing whether the underlying comparison is fair or useful.

William’s broader thesis is that internal software increasingly becomes a system of record—a database designed around a problem—with an AI interface on top. Three Pipes is his example: the agent gathers and enters information so he can move to the next responsibility.

Copy the recovery loop, not the permissions wholesale

William’s agents can retrieve context because he has given them extensive access: Google Suite, Linear, Notion, his calendar, QuickBooks, and other tools. He enables computer and browser use when an MCP connection cannot do the job.

His preference is effectively “allow always.” He initially described the bank as the only write-access exception, then also identified customer data as protected.

That is his risk decision, not a sensible default for every business. Broad access can reduce repetitive context transfer, but it also increases what an incorrect action can affect. A safer adaptation is to begin with read access and a narrow set of reversible writes, adding approval steps for consequential changes. That permission model is editorial guidance; it is not the setup William showed.

His recovery process is easier to recommend. When an agent gets stuck, he restarts it and tries again. Then he becomes more explicit: do this first, test this first, review the work, and check that it matches the request. More recently, he has had one agent drive and review work from his Cursor agent. If necessary, he switches agents.

A second agent’s review is another check, not proof of correctness. Someone still has to define success and inspect consequential results.

William’s closing concern was dependence: if the agents stopped working, how would he manage fifteen sales opportunities alongside hiring and everything else?

The verdict: copy his precise product briefs, explicit feedback, responsibility-based projects, and recurring operator questions. This approach is especially useful for founders and product-minded builders who understand the work but lack implementation capacity. Be much more selective about copying broad permissions or automated candidate rankings. The agents can write, retrieve, summarize, and check; deciding what good looks like—and what they should be allowed to change—still belongs to the human.