Custom apps: define v1 as one completable job
Retention depends on whether a target user can finish one full job on a weak network with little training. A feature race usually ships a v1 that cannot go live on its own.
Custom app projects often open with login, messaging, store, membership, content, and an admin console. Those capabilities may all be needed later. They are not the acceptance object for v1. Phase one should answer: after a named role opens the app, which job must complete, and how the system prompts and recovers when it fails.
The primary path matters more than screen count
Keep v1 on one path—field reporting, customer order and pay, in-store redemption, or inspection with photos. That path needs:
- Named roles and permissions, not a shared “admin” account
- Document states (submitted / rejected / done), not only “save draft”
- Weak-network and failure behavior: timeout, double submit, photo upload failure
- Reconciliation with existing systems: which fields the app owns, which write back to ERP or sheets
Personalization is not a new skin. It is modeling your documents, approvals, and field constraints. Templates speed a demo; once approval depth, pricing, or stock reservation diverge, rework costs more than rebuilding the primary path.
Let real usage shape v2
After launch, watch completion rate on the primary path, where people stall, and which steps still get screenshotted into group chat. v2 should fill gaps the data verified (offline cache, bulk import, supervisor views)—not turn the app into a feature set that needs a manual.
Write acceptance as a scenario, not a menu: “A warehouse operator confirms an outbound on a location with no Wi-Fi, and stock books reflect it within ten minutes.” If the scenario runs, you delivered. If menus open, you only integrated.