Building Miiro took 4 months of evenings and weekends. 270+ tasks tracked. 30+ TestFlight builds. Countless late nights after my son Miles went to sleep.

Here's what I learned along the way. Not the polished "10 tips for first-time founders" version. The real version, including the mistakes.

Start with your own problem

Every product advice article says this, but it's genuinely the biggest advantage you can have. My wife and I were the users from day one. Every feature decision came down to "would this make our morning easier?" Every design choice was tested by the person who'd use it every day.

When you build for yourself, you skip the customer research phase. You already know the pain points because you live them. You know which features matter and which are nice-to-have because you feel the difference.

Your partner is your best tester

My wife tested every build. She doesn't care about the technical implementation. She cares about whether adding a grocery item takes one tap or three. She notices when a button is slightly too small. She tells me when a flow feels confusing.

This kind of honest, daily feedback is worth more than any beta testing program. Find someone who will use your app every day and tell you exactly what's wrong with it.

Pick boring technology

I built Miiro with React Native (Expo), Firebase, and RevenueCat. Nothing exotic. Nothing bleeding edge. These are all proven, well-documented tools with large communities. For a deeper look at the technical decisions, read how we built Miiro from side project to the App Store.

The benefit of boring technology is that when things break (and they will), the answer is usually on Stack Overflow. When you're a non-technical founder working evenings, you can't afford to debug obscure framework issues at midnight.

That said, if I were starting a new project today, I'd seriously consider Supabase over Firebase. Miiro's hardest bugs came from Firestore's NoSQL model: security rules silently blocking writes, data living in the wrong collection, shared data ownership being more complex than it needs to be. A relational database with SQL-based security rules would have prevented most of these.

Simulator first, always

For the first several builds, I was testing directly on TestFlight. This meant every small fix required a full build, upload, and processing wait. It was slow and frustrating.

Then I discovered (embarrassingly late) that you can test on the iOS simulator. Instant feedback. Fix something, reload, see the result. I now do all development on the simulator and only build to TestFlight when the feature is working locally.

Cut features ruthlessly

My initial feature list was enormous. Smart notifications that learn your habits. Location-based reminders. Integration with Google Calendar and Outlook. Gamification. Voice input.

My wife kept asking: "But does the grocery list work properly yet?"

She was right. Every time I added a "cool" feature, it distracted from getting the core experience right. We shipped with tasks, calendar, meals, recipes, groceries, and Tell Miiro. Everything else is on the post-launch roadmap. If you're curious how Miiro compares to other options, we put together a roundup of the best household apps for couples in 2026.

The app we shipped is simple. And that simplicity is its biggest strength.

The hard truth about indie development

Building is harder than you'd think, but marketing is what I actually know. My day job is in marketing, so getting the word out felt natural. The harder part was learning to build the product itself. But that combination turned out to be an advantage. I understood the user because I am one, and I knew how to talk about the product because that's what I do for a living.

What I'd tell someone starting today

Build something you personally need. Use boring technology. Find one honest tester who will use it daily. Cut your feature list in half, then cut it in half again. Ship when it's good, not when it's perfect. And start marketing way earlier than you think you should.

Miiro isn't perfect. But it's real, it's in the App Store, and my family uses it every day. That's a pretty good starting point.

Frequently asked questions

What tech stack did you use to build Miiro?

React Native with Expo for the frontend, Firebase (Firestore, Cloud Functions, Auth) for the backend, RevenueCat for subscription management, and the Anthropic Claude API for Tell Miiro's AI-powered natural language parsing.

How long did it take to build Miiro?

4 months of evenings and weekends. The first version was a basic shared task list. By launch, it included a shared timeline, calendar, meal planner, recipe saver (Toru), auto-sorted grocery lists, and Tell Miiro AI input. For more on the build journey, read how we built Miiro from side project to the App Store.

Is Miiro available on Android?

Not yet. Miiro launched on iOS first. Android support is on the roadmap.


About the author: Robert is the co-founder of Miiro. He builds the app with his wife, who serves as chief tester and most honest critic. They live in the Netherlands with their son Miles.