An app sounds like progress. It is a concrete object. It has an icon, a store listing, and the appearance of a real product. For many teams, that gravity is exactly the problem. They ask for an app because they want the idea to feel finished, not because the situation requires software installed on a phone.
The moment of need decides the format
Kappa Card is a useful example. The problem was not “members need a mobile application.” The problem was an awkward networking moment: two people have just met, and neither wants to download something, create an account, or type details while the conversation is still happening.
If the solution required installation, it would fail in the only moment that mattered. A web-based experience that can be scanned immediately was the more disciplined answer.
What an app actually costs
Native apps bring store reviews, update cycles, platform differences, and a higher bar for adoption. Those costs are worth paying when the product needs device features, offline use, or a habitual place on the home screen. They are not worth paying as a default.
A first version should answer a business question: will people use this, and does it remove the friction we named? A well-made web experience or prototype often answers that question faster, with less waste, and with a clearer path to a later native build if one is still justified.
Ambition is not the same as usefulness
I am not opposed to apps. I have built them. I am opposed to letting the most ambitious-sounding format replace the actual problem. The job is to make something people can use when they need it—not to produce the artifact that photographs best in a pitch deck.
If you arrive with an app idea, we may still build an app. We may also build a site, a workflow, or a prototype that proves the idea before the heavier investment. The right solution is the one that solves the moment of need.
Kappa Card case study · Idea-to-Prototype Sprint · Start a project