My Velgrina work includes an Expo and React Native commerce application for iOS and Android. At the time of this project note, the application is in release preparation. I describe it that way deliberately: implementation progress and a verified public release are different milestones.
A commerce app can have a complete-looking set of screens while still needing work at the boundaries between them. Release preparation is where I look at the customer journey as a whole, especially the places where the phone’s view can diverge from the server.
Follow the basket across the application
The first review path starts with product discovery and continues through selection, basket changes and the next purchase step. The basket must remain understandable when the customer navigates backward, reopens a screen or changes a quantity.
I pay particular attention to a price or availability change while a customer is using the app. The displayed product is a view of server data at a moment in time. It cannot be the final authority for an order simply because it is already on the screen.
For that reason, my acceptance questions focus on reconciliation: does the customer see the latest accepted basket, are changed values explained, and can they correct a selection without starting the journey again? These are release criteria, not a claim that every scenario has already passed.
A shared codebase still has device behavior
React Native and Expo let me develop the application in a shared stack, but iOS and Android remain different environments. Keyboard behavior, navigation, permission prompts and app lifecycle changes can affect the same customer task in different ways.
I review physical interaction as well as layout. Can someone edit an address while the keyboard is open? Is a validation message still visible? Does returning from another application preserve enough context to continue? A screen can look correct in a static preview and still be difficult to use on a phone.
Long product names and translated text also deserve attention. A compact card design should not hide the information that distinguishes two variants, and a primary action should remain readable when a label takes more space.
Recovery is a customer-facing capability
Mobile connectivity makes ambiguous outcomes especially important. If a request is interrupted, the application may not know whether the server accepted it. Showing success too early is misleading; asking the customer to repeat an operation blindly can also create confusion.
For release preparation, I separate waiting, confirmed success, a definite rejection and an outcome that still needs checking. These states need understandable messages and appropriate next actions. “Something went wrong” gives a customer very little help when they are trying to complete a purchase.
Session expiry is another useful review case. A customer should know when authentication is required, and the application should avoid losing ordinary work unnecessarily. The server must still enforce access even when the client believes a session is valid.
Define what makes the release ready
My readiness checklist for a commerce application covers representative shopping journeys, device behavior, server validation, failure recovery and the operational information needed to diagnose a problem. Store submission assets and distribution configuration belong to the release process as well.
The checklist should produce specific evidence. “The app works” is too broad. “This basket change was accepted on both platforms, and a rejected quantity shows a recoverable message” is something another person can review.
Velgrina’s mobile application extends the commerce work into a different interaction environment. The useful engineering discipline is to keep implementation, validation and release status explicit. Preparing an app for customers means making the ordinary journeys coherent and the interrupted journeys recoverable, then checking those outcomes before calling the release complete.
Updated 26 September 2026.