Building Nuri for the days when something breaks

These two weeks did not go to plan

We had a plan for the last two weeks. Then the two weeks happened.

We wanted to spend the time polishing the app, starting distribution and bringing in more users. Instead, we spent a lot of it reacting to problems across Bitcoin, Lightning and different payment routes.

Honestly, it was exhausting.

Not because every problem was catastrophic. We are still early, and the number of affected users was manageable. But it felt like Groundhog Day: fix one moving part, another one changes, then a fallback stops working, then something else needs attention.

My first reaction was frustration. After thinking about it, though, the bigger lesson became obvious.

This is going to happen again.

I must say I feel exhausted after these two weeks.

Emin Mahrt · From the original recording

This is the environment we build in

Nuri connects many different financial systems. Banking, cards, Bitcoin, Lightning, local currencies and payment rails all behave differently. Some parts are ours. Some parts connect us to outside infrastructure. Every part can change, go into maintenance or temporarily stop working.

Everyone in this space is building difficult systems, including us. Changes and interruptions are part of that work. We chose to bring these systems together, so the experience users have when something changes is our responsibility.

Our job is not to pretend every moving part will work perfectly forever. Our job is to make sure Nuri remains useful when one of them does not.

if you're building a puzzle with many moving parts, of course, those moving parts are going to work, going to not work, going to break.

Emin Mahrt · From the original recording

A fallback must work when you need it

The most frustrating moment was not that a feature stopped working. That can happen.

The frustrating part was discovering that a fallback was no longer available in the situation where users needed it.

That taught us something very simple: a fallback that only works under normal conditions is not much of a fallback.

We need to keep removing single points of failure wherever we can. Sometimes that means adding another route. Sometimes it means letting users recover or exit without depending on us. Sometimes it simply means separating two features that look similar but fail for completely different reasons.

Bitcoin and Bitcoin Lightning are a good example. To many users, they may look like two versions of the same thing. Technically, they are very different systems with different tradeoffs and different ways of failing. Presenting them as one seamless balance may look cleaner, but it also means a Lightning problem can make the entire Bitcoin experience feel broken.

For now, separating them is more honest and more useful. Bitcoin can continue working when Lightning is unavailable. Lightning can clearly show its current status. Users should not need to understand the technical reason. They only need to know what works, what does not, and what they can do next.

We tried too hard to hide the machinery

For a long time, I wanted Nuri to hide all the complexity.

That is still the goal in many places. Nobody should need to understand nodes, liquidity, payment routing or infrastructure providers to send money.

But hiding complexity cannot mean hiding reality.

If a route is temporarily unavailable, the app should say so. If something is under maintenance, it should look like it is under maintenance. If a currency is supported as a payment route but not as a balance, the interface should make that difference clear.

We previously tried to avoid messages like "temporarily unavailable." They felt technical and unfriendly. Looking back, that created a worse experience. A button that looks available but fails after you press it is much more frustrating than a grayed-out button with a clear explanation.

This changes how we think about the main Nuri screen. It should not only show where your money is. It should also show what you can currently do with it.

You may have money in euros, but several ways to use those euros: card payments, bank transfers or conversion into another currency. Some payment rails do not need their own balance at all. They are simply another way to send or receive money.

At the same time, we must never show the same money twice. If your card and bank account use the same underlying balance, displaying that amount under both can make it look like you have twice as much money as you actually have.

The first version may not be beautiful, but it must be clear.

Support should know what the app knows

This week also changed how I think about support.

Support should not be a separate system with an outdated list of features. It should understand the same Nuri that the user is looking at.

If a route is unavailable, support should know immediately. If a feature has been disabled, our support agent should not recommend it. If somebody asks why they cannot pay a Lightning invoice, support should be able to see whether the route works, explain the current situation and suggest an available alternative.

This is where our MCP work becomes practical.

MCP sounds technical, but the basic idea is simple: we want every Nuri capability to be available through a clean interface that both the app and agents can understand.

The Nuri MCP should contain the features that are genuinely available in Nuri. Experimental features should live somewhere else until they are ready.

Right now, those boundaries are not always clean. We have experiments, app features and independent services living too close together. That made sense while we were moving quickly and testing ideas. It makes less sense now that we want agents to support real users.

When something becomes available in Nuri, the support agent should understand it. When something disappears from the app, it should also disappear from the agent's available actions. App, support and infrastructure should describe the same reality.

We are not waiting for perfection

We can spend months designing the perfect fallback for every possible failure. Then we launch and discover that users are confused by something completely different.

We need real users.

We need people to open Nuri, try to use it and tell us where they get stuck. Not because they have a theory about our interface, but because they wanted to do something and could not.

That feedback is more useful than ten internal opinions.

One example came up around separating cards and bank transfers. From a technical perspective, putting them together can look logical because they may share a balance. But users repeatedly asked where their IBAN was. They opened the card screen, saw a card and stopped looking. They did not expect bank transfers to be hidden there.

Users do not need to know why we originally grouped two things together. They only know that they could not find what they needed.

So we will move faster with rough screens and rough flows. Then we will watch where people struggle and improve those parts. Some things will not look perfect, and some experiments will fail. An idea can make sense in a meeting and feel wrong the moment somebody tries it.

We would rather learn that now.

it's okay that things break it's okay that they don't look good we just react on it and basically make the best out of it

Emin Mahrt · From the original recording

What we are doing next

We will keep improving the app, but we will also start bringing more people into it. Distribution cannot remain the task we postpone whenever something breaks.

We are separating features so one unavailable route does not damage the rest of the experience, adding clearer status information, and cleaning up the Nuri MCP so it matches the app. Support should know which capabilities are live. Better monitoring will help us find problems before they turn into long support conversations.

For Lightning, we will look at the available options without rushing into another permanent dependency.

There are several possible steps. We can support regular swaps between Bitcoin and Lightning, investigate faster versions later, review other non-custodial approaches, or keep improving our current integration when the required capabilities become available.

We do not need to make every decision today.

Bitcoin can remain useful without pretending every Lightning use case is already solved. Lightning is difficult, and the wider industry is still working through some hard problems. We would rather be honest about that than force a seamless-looking experience that becomes confusing when something changes.

The same principle applies beyond Bitcoin. If one local currency route goes into maintenance, the rest of Nuri should continue working. If a card service is unavailable, users should still find their bank transfer options. If a feature is experimental, it should not quietly appear as if it were production-ready.