Building Monveo: lessons from shipping an AI finance app to 21k+ users

Monveo is an AI personal finance app I build and run. It is available on iOS and on the web, and it has passed 21,000 users. Most of my working days are spent designing for other founders, so building my own product has been a useful mirror. It shows me which of my design opinions hold up when I am the one paying for every mistake.

This post is not a growth playbook. It is a list of things I learned while shipping Monveo as a designer who also writes a fair amount of the code.

What Monveo does

The idea is simple: tracking money should take seconds, not willpower. You can log an expense by speaking ("coffee, 35 thousand"), by scanning a receipt, or through Siri Shortcuts without opening the app. On top of that, Monveo gives you budgets and plain-language insights about where your money goes.

The app is built with React Native and Expo, with Supabase as the backend. That stack lets one person ship to iOS and web from mostly the same codebase, which matters a lot when the team is just you.

Lesson 1: the input is the product

Every finance app has charts. The reason people quit these apps is not the charts. It is that entering transactions is tedious, so they stop doing it, and then the charts are empty.

So I spent most of my design time on input, not on dashboards. Voice entry, receipt scanning, and Siri Shortcuts all exist to answer one question: how do we make logging an expense so fast that you do it while you still remember it?

The broader lesson, which I now bring to client work: find the one action your product depends on, and make that action almost effortless. Everything else is secondary until that works.

Lesson 2: AI should remove steps, not add a chat window

When I added AI features, the tempting move was a chatbot. I tried versions of it. What actually helped people was quieter: AI that parses "lunch with team 120k" into an amount, a category, and a date, so the user only has to confirm.

Good AI features in a consumer app often look like nothing at all. The user does less, and the app gets it right. When the AI is unsure, the design should show its guess and make correcting it a single tap. Trust comes from being easy to fix, not from being perfect.

Lesson 3: design for the second week

The first session is easy to design for. People are curious, they explore, they set up a budget. The hard part is the second and third week, when the novelty is gone.

I learned to judge features by asking whether they help someone come back. Reminders that are timed well, a weekly summary that says something specific, and a budget that warns you before you overspend, not after. Small things, but they shape whether the app becomes a habit or a forgotten icon.

Lesson 4: one codebase, two platforms, honest compromises

React Native and Expo let me ship iOS and web together, which was the right call for a solo builder. But "write once" is never fully true. Some interactions that feel natural on a phone, like swiping a transaction away, need a different pattern with a mouse and keyboard.

I stopped trying to make both platforms identical. Instead I kept the same information and the same flows, and let the controls follow each platform's habits. Users don't compare the two side by side. They just want the one they are using to feel right.

Lesson 5: being designer and founder changes your priorities

As a designer on a client team, I care a lot about polish. As a founder, I care about polish only where users will feel it. I shipped screens I wasn't fully happy with because the time was better spent on something that affected retention.

That sounds like lowering the bar, but I think it is the opposite. It made me much clearer about where craft matters most: the first screen, the core action, and anything involving money or trust. In a finance app, a confusing number does more damage than an ugly button.

Lesson 6: Supabase made the boring parts boring

Authentication, a Postgres database, storage for receipt images, and row-level security came mostly out of the box with Supabase. For a one-person team that is a big deal. Every hour I didn't spend on infrastructure went into the product.

My advice to designer-founders is to pick tools that let you avoid building anything a user will never see, at least until you have to.

What carries over to client work

Building Monveo changed how I work with the founders in my studio. I ask about the one critical action earlier. I push for AI features that remove steps rather than add screens. And I am more comfortable shipping something good enough today and improving it next week, because I have seen how much faster you learn that way.

Monveo is still a work in progress, and I will keep writing about what I learn as it grows. If you are a designer thinking about building your own product, my main advice is to start smaller than you think and make the core action ridiculously easy. The rest can come later.