What a mobile app project with D&C looks like
An app is a small promise to be useful again next week. The download is the easy part. The real test is the second open, then the fifth, then whether the icon survives the next time someone clears space for photos. Everything below is how we design for that moment.
Start with the job, not the feature list
Every project begins in Listen & Learn with one question: what will this app do better than your website? For a D2C skincare brand in Dubai, the answer was letting regular customers reorder their routine in two taps. For Ekeeda, it was getting learners to the right lecture quickly, on whatever phone and connection they had. The feature list comes afterwards, ranked against that job, and most apps ship stronger for what we leave out of version one.
Flutter, React Native or native: how we choose
We build in all three and gain nothing from picking one, so the decision is written down with its reasons during Map & Measure.
- Flutter draws every pixel itself, so a highly custom brand, rich animation and identical behaviour on iOS and Android come naturally. It is often our pick for consumer and commerce apps with a strong visual identity.
- React Native uses each platform’s own interface components and speaks TypeScript. It shines when your web team already works in React, because code, tooling and people can move between the website and the app.
- Native Swift and Kotlin cost more, because you maintain two apps, and they earn it when the product lives on the hardware: AR, camera pipelines, Bluetooth devices, background location, widgets, or new OS features on the day they arrive.
The question that settles most of these debates is not speed. It is who will maintain the app in year two, and what they already know.
Built for the phone in your customer’s pocket
There is a drawer in the Mumbai studio full of test phones. The one that matters most is a three year old Android that cost under ₹10,000 when it was new. Nothing ships until it feels quick on that phone over a throttled connection, because it is far closer to your typical customer than the flagship on the founder’s desk. Prem, one of our founders, asks the same thing in every review: would this still work for a million people on a cheap phone and a patchy connection?
We also test with VoiceOver and TalkBack, with larger text sizes and with one thumb, because accessibility belongs in the build, not in an audit six months later.
Launch is a staged rollout, not a leap
We prepare the store listings, privacy labels and review notes, release to a small share of users first and watch the crash rate before opening the doors wider. As Suraj likes to say, if launch day is exciting, we did something wrong in the weeks before it.
After the store listing goes live
Apple and Google change the rules every year, and a new OS version lands every autumn. Our Care & Grow plans absorb that: OS updates, policy changes, crash monitoring and a quarterly look at retention with you. Apps rarely fail on launch day. They fail slowly, when nobody is looking after them. We started life keeping websites online, and we bring the same habit to every app we ship.
See how it played out for Ekeeda and the Dubai skincare brand, read our guide to app development costs, or tell us what you are building.