What We Learned Building a 100+ Screen Flutter Dating App

Indore, 1 November 2026, I finally sat down to write up what the biggest app we have built so far taught us. The product is Keen as Mustard, a dating app made only for Australians, built for two co-founders in Sydney, Josie and Ryan. When two people match, they get access to discounted real-world experiences at restaurants, cafes, cinemas and pubs. The point is to get people off the app and into the same room.

The scope was big for a team our size. A Flutter app for iOS and Android with more than 100 screens, a Node.js backend with over 50 API endpoints, a React landing page and a React and Node.js admin panel. Six of us built it in six months and delivered on time. The founders later paused the store launch for personal reasons, so you won't find it in the App Store. The build itself is finished.

What follows is roughly in the order the problems showed up.

Why we picked Flutter for a dating app

A dating app lives or dies on how it feels in the hand. Swiping, profile cards, chat, filters, lots of small animations. The founders needed iOS and Android at the same time, and two codebases drifting apart over six months was not something anyone wanted. Flutter gave us one UI layer that renders the same way on both platforms. With 100+ screens to keep in line, that mattered more than anything else on the list.

I won't pretend Flutter is the answer for every product. I wrote up the trade-offs in our Flutter vs React Native guide if you are weighing it up. Here, with one team owning every screen, it was an easy call.

The rest of the stack was fairly standard for us. Node.js for the API, Firebase for the real-time parts, RevenueCat for premium subscriptions, AWS for hosting, and React for both the landing page and the admin panel. Nothing exotic. On a project this size I like boring choices.

Keeping 100+ screens consistent

No single screen was the hard part. Getting screen 73 to look like it belongs to the same product as screen 4 was.

Our rule is that no code gets written until the client has signed off the design in Figma. Our lead designer designed every screen, and we went back and forth with the founders until they approved them. On smaller projects this can feel slow. On Keen as Mustard it is the main reason the app stayed coherent. Developers built from a finished, agreed design, so nobody was inventing spacing, colours or button states halfway through a sprint.

The feature list shows why:

• Discovery mode and passport mode for browsing matches
• Keen and super keen likes, plus real-time chat
• Personality and trait filters, privacy controls and contact blocking (which hides you from people in your phone contacts, both ways)
• Premium subscriptions through RevenueCat and weekly giveaways
• Dual verification with a permanent verified badge

Each of those touches several screens, and most need something in the admin panel too. Had design and build run in parallel, we would have been redoing screens every week. If you are planning something similar, put design sign-off in the plan as an actual milestone with a date on it. Our UI/UX design process is built around that.

The trademark problem, four months in

The app was originally called Match at First Swipe. About four months into development, it turned out the name could not be trademarked. So the product needed a new name, logo, colour palette and identity, with roughly two months left on the timeline.

It became Keen as Mustard, in mustard gold, violet and teal, set in Plus Jakarta Sans. We did the rebrand with no change order and no paused sprint, at no extra cost to the founders, and still delivered on time.

I don't want to oversell that. It still meant fresh design work and a pass over every screen that carried the old name or colours. Having every screen already designed and approved in Figma made that pass manageable rather than chaotic. I would still rather not do it again.

I'll come back to what I would do differently at the end.

Dual verification and trust

Dating apps have a trust problem. People want some confidence that the person on the other side is real, and verification sits at the centre of Keen as Mustard for that reason.

We built dual verification. A user takes a live selfie that goes through a liveness scan, and then their face is matched against a government ID. Pass both and you get a permanent verified badge. The admin panel handles verification along with moderation, giveaways and subscriptions, so the founders don't need a developer every time something needs a human decision.

Two pieces of advice from this part. Design the failure states as carefully as the happy path: a bad photo, poor lighting or an ID that does not match all need clear, polite screens, or people give up halfway. And give the admin panel proper attention. The founders use it every day, and it is easy to leave it until last.

Testing with 546 people before launch

Test builds went out through TestFlight on iOS and Google Play internal testing on Android for the whole build. By the largest build, 546 internal testers had the app. That changes how QA works.

With a handful of testers, you can read every message and reply. With hundreds, you have to sort feedback into real bugs, design questions and personal preference, and a lot of reports turn out to be the same issue described in different words. Our internal QA still did the structured testing and edge cases. The wider group showed us where real people got confused.

Weekly progress updates helped too. The founders could see what had changed each week and try it on their own phones instead of waiting for a big reveal. Our app development process page has the full sequence.

500+ signups before the app was out

While we built the app, the React landing page was collecting interest. It brought in more than 500 pre-launch signups. For a dating app that matters more than for most products. An empty dating app is a dead one.

My view: build the landing page early. Don't leave it for launch week. It is a small job next to the app, and it gives the founders a waiting list to work with while the hard engineering is still going on.

What I would keep, and what I would change

I would keep the design sign-off rule exactly as it is. I would keep one team owning the app, backend, admin panel and landing page, because nobody had to chase another vendor when something crossed those lines. And I would keep shipping test builds every week.

The thing I would change is when the name gets checked. A basic trademark check belongs in discovery, before the name appears on a single screen. It is a short question, and on this project it would have saved a rebrand. Nobody, us included, raised it early enough.

At the end of the project Josie wrote that they had "learnt a great deal from you during this process". It went both ways. The full case study, with screens, is on the Keen as Mustard project page. If you are planning a dating app of your own, our dating app development page covers how we would approach it.