On the counterintuitive sequencing decision that shapes everything else
The standard advice for building a consumer app is to start with the interface. Users don't experience your architecture. They experience what they see and touch. So build the thing they'll see and touch first, get it in front of people, learn what they actually want, and build the infrastructure later when you know what you're building it for.
This advice is usually right. It's why the lean startup methodology works as well as it does, why MVP culture has produced so many successful products, and why founders who spend two years building perfect backends before showing anyone anything tend to build beautiful, useless things.
I'm deliberately ignoring this advice for Yuko. Here's why.
The Interface Is Not the Product
Most productivity apps start with an interface that helps you capture and organize tasks. The interface is clean, the categories are intuitive, the design is satisfying. You set up your lists, maybe do some onboarding, and feel the familiar optimism of a new system.
Then, after a few weeks, you stop using it. The capture was easy. The execution was still your problem.
If I build Yuko starting with the interface — the places you set reminders, choose your goals, customize your notification preferences — I will build something that looks like every other productivity app. The interface would be the product, in the sense that it would be what users evaluate and what reviewers describe. But the interface is not actually what makes Yuko different.
What makes Yuko different is the engine. The system that decides when to send a nudge, in what format, through which channel, with what framing, based on what it knows about this specific person's behavior patterns and stated motivations. That decision engine is Yuko's actual product. The interface is the access point.
Building the interface first means building the access point before you have anything worth accessing. You get a beautiful door that opens onto an empty room.
What the Engine Actually Needs to Do
To understand why the engine is hard, it helps to be specific about what it needs to do well.
It needs to know, for a given task at a given moment, what the probability is that a nudge right now will produce action — versus being dismissed, ignored, or resented as an intrusion. This is a function of the time of day, the user's recent activity, the task's history of completion and deferral, the channel fatigue on each delivery medium, and the user's current cognitive state as inferred from behavioral signals.
It needs to choose, given that a nudge is appropriate, what form it should take. The decision involves tone (direct, warm, humorous, reflective, urgent), length (brief acknowledgment vs. richer contextual framing), channel (SMS, email, push, or something else), and specific phrasing — ensuring that the message doesn't repeat something the user has already received and habituated to.
It needs to maintain, over time, a representation of each user's goals that is more than a label. It needs to understand the stakes behind each goal, the people connected to it, the timeline it operates on, and why it matters to this specific person — so that the motivational context it surfaces is genuine rather than generic.
And it needs to learn from what actually happens. When a nudge produces action, the engine should register what worked: the timing, the tone, the channel, the framing. When a nudge is consistently ignored, the engine should update its model. The learning loop is not a nice-to-have. It is the core mechanism by which the engine gets better.
This is genuinely hard to build. It requires a model of human behavior that is specific enough to be actionable and general enough to work across different people and different types of goals. It requires inference from behavioral signals that are noisy and indirect. It requires the judgment to distinguish between a task that needs a different approach and a task that the user has implicitly decided not to do — which are not the same situation and warrant different responses.
Why Starting Here Changes Everything
Building the engine first changes the product in a way that building the interface first wouldn't.
When you build the interface first, you make dozens of design decisions that implicitly commit you to a mental model of how the product works. The reminder card with its customizable fields commits you to a model where users specify their own motivational context. The notification settings screen commits you to a model where users control their own delivery preferences. The onboarding flow commits you to a model where users define their goals explicitly at the beginning.
These are all reasonable design patterns. They're also all patterns that put the intelligence burden on the user — expecting people to know what they need, when they need it, how to ask for it.
The engine I want to build inverts this. It doesn't ask users to specify all the conditions for an effective nudge. It infers them. It doesn't require users to maintain motivational context for each goal. It surfaces that context dynamically. It doesn't ask users to design their own notification schedule. It derives a better one from behavioral data.
This inversion changes what the interface needs to do. The interface becomes simpler — not a complex configuration panel for all the variables the engine manages, but a lightweight layer for setting goals, providing context, and reviewing the engine's outputs. The intelligence lives in the engine. The interface just makes it legible.
If I build the interface first, without the engine, I build an interface designed for a different product — one that puts the intelligence burden on users in the way that every existing productivity app does. Retrofitting the engine later means fighting the design commitments made without it.
What I'm Actually Building
The reminder engine is not a notification scheduler. It is a decision system that combines a few components:
A behavioral model, trained on each user's history of task completion and deferral, that produces probability estimates for nudge effectiveness across timing, channel, and task-type dimensions. A motivational model that maintains a dynamic representation of each user's goals, stakes, and reasons — updated as circumstances change and as the user provides feedback, explicit or implicit. A generation layer that produces nudge content that is fresh, contextually specific, and calibrated to the tone and register appropriate for this moment.
The AI layer — Claude, in the current prototype — is central to both the motivational model and the generation layer. The behavioral model is more traditional machine learning over behavioral signals. The combination is what makes the system behaviorally intelligent rather than just algorithmically scheduled.
The interface will come. The product will need to be legible, and legibility requires design. But the design will be built to express the engine's capabilities, not to substitute for them.
The Risk of This Approach
I want to be honest about the risk.
Building the engine first means that early users will experience something rougher than a polished app. There will be more configuration friction. The first version of the motivational model will make errors — surface reasons that feel off, miss context that matters, occasionally misread the moment. The learning loop will need time to produce its benefits.
The risk is that rough early experiences lead to poor retention before the engine has time to learn. This is a real risk, and it argues for being deliberate about who the early users are — people who understand what they're signing up for, who can tolerate the rough edges, and whose feedback will accelerate the learning loop faster than a mass launch would.
It's a smaller, more patient early access group in service of a product that actually works when it reaches scale.
The apps that look polished from day one and do nothing differently are not the ones worth building. The engine is the bet. Everything else is in service of it.
Yuko is in early development. If you're interested in being part of the group that helps train the engine — and willing to trade some polish for genuine novelty — join the early access list at yuko.ai
