A business app is a client plus a backend. We design who signs in, what they do first, and which APIs the old versions can still call after you ship a new build.
Employee tools, customer portals, or channel apps are three different information architectures. Offline use, push wake-up and store listing are the usual reasons to leave a browser-only product.
If Android and iOS share the same screens and you are not deep into custom camera or Bluetooth stacks, cross-platform cuts duplicate UI logic. Modules that must be native are named in the proposal—we do not promise “one codebase forever” in the abstract.
App Store review, privacy manifests and payment rules are on the critical path. Play / other Android stores add signing and device coverage. Review material is scheduled, not written the week you hope to publish.
Users, content, orders and config live on the server. APIs need versions, auth and audit. The console your operators use is not the same permission model as the app binary.
A first version with login, lists and a simple transaction is often 8–14 weeks of build, plus store review. Chat, media or heavy offline work takes longer.
If you need deep native sensors, two native apps can be safer. If the product is information and transactions with similar releases, cross-platform can cover both, with native islands later.
A first version with login, lists and basic transactions is often 8–14 weeks of engineering, plus store review. Real-time messaging or offline field work stretches that.
Mini programs win inside WeChat. An app is for home-screen presence, push, richer offline use or store branding. Both can share one backend.
We deliver the clients, the operator console and the APIs together—including permissions, logs and a release plan. An IPA or APK alone is not a product.
We use this only to scope the project. No marketing list.