Web, mobile, or both — how to choose for a business product

Teams often ask for “an app” when they mean “software people will use.” Those are not the same request.

A customer portal used at a desk should be a web application. A field tool used with one hand should be mobile. A consumer product that lives in someone’s pocket needs iOS and Android. A SaaS product used by operators all day is almost always web first.

Choose the primary surface

Pick the place the product must be excellent. Build that properly. Put a shared API and domain model behind it so a second surface is an addition, not a rewrite.

Native iOS and Android still matter when you need platform features, performance or a store presence. React Native and Flutter are the right call when one team has to ship both platforms without pretending they are identical.

We build all of those. The web and mobile practice is the core of the company for a reason: most real products eventually need more than one surface.

Do not start from the store listing

An App Store icon is not a strategy. Permissions, offline behaviour, notifications and device APIs are. If you do not need them, a well-built web app will beat a thin wrapper.

If you do need them, budget for them. Mobile is not a reskin of the website.

Architecture that survives the second platform

• One backend and one set of business rules
• Auth and roles that work on every client
• APIs designed as a product, not as leftovers from a page
• A design system that can flex across screen sizes without becoming a different application

That is also how we take products from idea to production without painting the team into a corner.

See also: LawyerdUp and our work.