Building AI Apps People Love: Lessons from the Studio

Building an AI app is easy to start and hard to finish well. The demo works on the first try, the screenshots look magical, and then you spend the next six months on the unglamorous parts: what happens when the model is wrong, how someone understands the app in the first thirty seconds, what you charge, and what you say no to. At Sépia, a small studio in Montréal, we design and ship focused AI apps end to end — MyoScore, PrettyType, Debate — and most of what we've learned the hard way lives in the articles collected here. This is the overview. The deep dives are where the specifics are.

If you're a builder shipping with a small team, the trap isn't a lack of ideas. It's the opposite. AI makes almost any feature feel reachable, so the discipline shifts from can we build it to should we, and what does it cost us to maintain. Everything below is downstream of that question.

Focus beats scope, every time

The most expensive decisions you make are the features you keep. Each one adds surface area to test, onboard, explain, and support — forever. Small teams don't lose because they build too little; they lose because they spread thin and ship six mediocre things instead of one that's genuinely good.

We've written about why focused apps beat bloated ones, and the short version is that focus is a feature users can feel. A tool that does one thing clearly earns trust faster than a suite that does ten things adequately. The flip side is operational: a focused app is something a small team can actually ship and keep alive without burning out. The constraint isn't a limitation. It's the strategy.

• Cut early, not late. The feature you're unsure about will be the one that drowns you in edge cases.
• Depth over breadth. One workflow that feels finished beats five that feel like betas.
• Say no on the record. Write down what the app is not, so scope creep has something to argue against.

The model is a component, not the product

This is the mistake we see most: treating the model as the whole experience. It isn't. The model is one part — a powerful, unpredictable part — sitting inside a product made of UI, copy, defaults, error states, and the thousand small choices that decide whether someone trusts the output.

Users don't experience your model. They experience your app on a bad day: the slow response, the confidently wrong answer, the result they can't tell is right. So the real work is engineering around imperfect output — and that's the heart of designing trustworthy AI features people actually believe in. Trust isn't a marketing claim. It's built from honesty about uncertainty, graceful failure, and giving people a way to verify or correct what the model produced.

An AI feature that's right 90% of the time and honest about the other 10% beats one that's right 95% of the time and silent when it's wrong. Users forgive errors they can see coming. They don't forgive being misled.

AI changes the rules of design

Conventional mobile design assumes deterministic output: tap a button, get a known result. AI breaks that assumption. Responses vary, latency is real, and the screen has to communicate confidence, progress, and the occasional miss — without making the whole thing feel fragile.

That shift touches everything from loading states to how you present a result you're not fully sure of, which is why we pulled it into its own piece on how AI rewrites the rules of mobile design. A few principles we keep coming back to:

• Design for the wait. Latency is part of the UX now. Make it feel intentional, not broken.
• Show your confidence. Let the interface signal when output is solid versus when it's a best guess.
• Make correction cheap. The easier it is to fix or regenerate, the less a wrong answer costs you in trust.

Onboarding and pricing: where good apps quietly die

You can build a focused, trustworthy, well-designed app and still lose people in the first minute — or fail to make a dollar from the ones who stay. Onboarding and pricing are the two places where most of the value either lands or leaks, and both get far less attention than they deserve.

Onboarding an AI app is its own problem because you're not just teaching navigation, you're setting expectations about what the model can and can't do. Promise too much and the first wrong answer feels like a betrayal; promise too little and people never see the magic. We get into the balance in onboarding an AI app without losing the room — getting users to a real win fast, before the explaining starts.

Pricing is where indie builders flinch hardest, especially when there's a per-request cost behind every interaction. Underprice and you subsidize your own users into the ground; overcomplicate it and nobody converts. Our take on pricing an indie app without flinching is about charging for the value you deliver, staying honest about your unit economics, and not apologizing for needing the business to work.

Deciding what to build next

Every studio's roadmap is really a series of bets. With a small team and real costs per feature, picking wrong twice in a row can sink a quarter. The hard part isn't generating ideas — it's having a process honest enough to kill the ones that won't pay off, including the ones you're personally attached to.

We laid out our actual framework in how we decide what to build next: how we weigh user pull against maintenance cost, how we tell a loud request from a real need, and why not building something is often the highest-leverage call you'll make all month. It ties the rest of this together — focus, trust, and economics all show up the moment you have to choose.

Where to start

If you're early and figuring out whether you can even ship this with the team you have, start with what it takes to ship with a small team. If you've already got something live and you're fighting wrong answers and lukewarm trust, go straight to designing trustworthy AI features. None of this is theory. It's the residue of shipping real apps, getting parts of it wrong, and writing down what we'd do differently — so you can skip a few of the mistakes we didn't.